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FOREWORD 


The Systems Technology Laboratory (STL) is a computational 
research facility located at the Goddard Space Flight Center 
of the National Aeronautics and Space Administration (NASA/ 
GSFC) . The STL was established in 1978 to conduct research 
in the area of flight dynamics systems development. The 
laboratory consists of a VAX-11/780 and a PDP-11/70 computer 
system, along with an image-processing device and some 
microprocessors. The operation of the Laboratory is managed 
by NASA/GSFC (Systems Development and Analysis Branch) and 
is supported by SYSTEX, Inc., Computer Sciences Corporation, 
and General Software Corporation. 

The main goal of the STL is to investigate all aspects of 
systems development of flight dynamics systems (software, 
firmware, and hardware) , with the intent of achieving system 
reliability while reducing total system costs. The flight 
dynamics systems include the following: (1) attitude deter- 

mination and control, (2) orbit determination and control, 

(3) mission analyses, (4) software engineering, and (5) sys- 
tems engineering. The activities, findings, and recommenda= 
tions of the STL are recorded in the Systems Technology 
Laboratory Series, a continuing series of reports that in- 
cludes this document. A version of this document was also 
issued as Computer Sciences Corporation document 
CSC/TM-80/6233. 
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ABSTRACT 


This document provides the requirements definition and anal- 
ysis for the prototype version of the Automated Orbit Deter- 
mination System (AODS) currently being developed at Goddard 
Space Plight Center's System Technology Laboratory 
(Code 580) . Specified herein are the AODS requirements at 
all levels, the functional model as determined through the 
structured analysis performed during requirements defini- 
tion, and the results of the requirements analysis. Also 
specified are the implementation strategy for AODS and the 
AODS-required external support software system (ADEPT) , in- 
put and output message formats, and procedures for modifying 
the requirements presented in tnis document. 
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SECTION 1 - INTRODUCTION 


This document provides the requirements definition and anal- 
ysis for the prototype version of the Automated Orbit Deter- 
mination System (AODS) currently being developed at Goddard 
Space Flight Center's (GSFC's) System Technology Laboratory 
(STL) , Code 580. This prototype system will demonstrate, in 
a laboratory environment, the feasibility of using 'micro- 
processors to perform onboard orbit determination in an 
automated manner with limited ground support. It is antici- 
pated that this prototype system will be used as the basis 
for an experimental flight system to be flown on a mid-1980 
mission. The orbit determined on board could be used to 
provide both position and velocity for scientific experiment 
data annotation and predicted one-way Doppler data for re- 
ceiver acquisition. This document also includes a discus- 
sion of the external support software required by AODS. 

This software system, named ADEPT for AODS Environment Simu- 
lator for Prototype Testing, provides the external informa- 
tion required for AODS operation and monitors AODS 
performance. The system requirements of the actual flignt 
experiment are not addressed in this document. 

AODS will be developed on STL's PDP-11/70 computer under the 
RSX-11M operating system. The target computer will be the 
LSI-11/23 microprocessor under the RSX-11S operating sys- 
tem. .Since the LSI-11/23 supports FORTRAN IV Plus and 
double-precision arithmetic, it is well suited for complex 
computational problems such as orbit determination. ADEPT 
will be fully implemented on che PDP-11/70. 

Section 2 of this document specifies the AODS requirements 
at all levels and the functional model as determined througn 
the structured analysis (Reference 1) performed during re- 
quirements definition. Section 3 presents the results of 
the requirements analysis, including timing and sizing 
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studies, operational scenario, throughput analysis, and er- 
ror contingency plan. Section 4 specifies the implementa- 
tion strategy for AODS and ADEPT for both current and future 
implementation. Appendix A states the ground rules for the 
data flow diagrams provided in Section 2. Appendix B con- 
tains the data dictionary that is referred to throughout the 
document. Appendix C specifies the input and output message 
formats. Appendix D specifies the procedures for modifying 
the requirements presented in this document. Appendixes E 
and F present additions and changes made to this document 
after its initial publication in September 1980. Appendix E 
describes the recommended estimation logic for AODS, and 
Appendix F contains a list of updates made to the AODS re- 
quirements definition document as a result of the new esti- 
mation logic. 
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SECTION 2 - REQUIREMENTS DEFINITION 


This section specifies the AODS requirements that have been 
determined through the system definition phase of require- 
ments analysis. Given a basic set of requirements and the 
information gathered from extensive interviews with GSFC, a 
formal methodology, structured analysis (Reference 1) , was 
used to build a preliminary model of the system. Then, 
through a series of requirements reviews, this model was 
iteratively enhanced until the desired system model was ob- 
tained. The model v'f AODS then served as the center of dis- 
cussion through which a more extensive requirements list was 
generated. 

The AODS requirements specified in tnis section are pre- 
sented according to level of detail, as follows: 

• .Seccion 2.1 specifies the system requirements, 

which are the tasks the system must perform (on the 
highest level) to satisfy the needs and objectives 
of the end user. 

• Section 2.2 specifies tne system performance re- 
quirements and limitations, which consist of the 
schedules on whicn specific requirements must be 
satisfied and any limitations that will affect the 
performance of the system. 

• Section 2.3 specifies the functional requirements, 
wnich are the functions the system must perform to 
satisfy the system requirements. These are the 
most detailed requirements given. In addition, the 
section provides a functional decomposition of the 
system, corresponding data flow diagrams, and re- 
quirements maps to demonstrate the completeness of 
the AODS functional model and provide a cross- 
reference of the functional requirements. 
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• Section 2.4 presents the functional specifications, 
which are the computational models and procedures 
that have been specified to date. 

2.1 SYSTEM REQUIREMENTS DEFINITION 

AODS will be an onboard orbit determination system requiring 
periodic ground support. The objective of AODS is to pro- 
vide the outside world with orbit information (i.e., posi- 
tion and velocity) on a near-real-time basis for 

experimental data annotation. 

— * 

Since the prototype AODS will be built and demonstrated in a 
laboratory environment, the external world, including the 
ground support system, will be simulated by ADEPT. Fig- 
ure 2-1, the AODS context diagram, shows the relationship of 
the prototype AODS to its external environment. 

This section specifies the system requirements, i.e., the 
tasks that the prototype AODS must perform to satisfy the 
needs and objectives of the end user. These requirements 
include the top-level AODS requirements, presented in Sec- 
tion 2.1.1, and the input and output requirements, presented 
in Sections 2.1.2 and 2.1.3, respectively. 

2.1.1 TOP-LEVEL REQUIREMENTS 

The top-level requirements of AODS are as follows: 

• AODS will provide position and velocity on a near- 
real-time basis for experimental data annotation 
and direct downlink. 

• AODS will predict one-way Doppler observations on a 
scheduled basis and output them for receiver acqui- 
sition. 

• AODS will generate and output a state vector pre- 
dict table containing vectors at a specified fre- 
quency over a specified time interval. 
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Figure 2-1. AODS Context Diagram 
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AODS will maintain and output an activity log on a 
tegular oasi3 and when specifically requested 
through a control command. 

• AODS will perform any preprocessing required to 
process the input raw tracking data. 

e AODS will be capaole of recovering from both user 
spacecraft and Tracking Data and Relay Satellite 
( TDRS ) maneuvers, 

• AODS will perform orbit determination using a catch 
least-squares method of estimation, differentially 
correcting the orbit of tne target (user space- 
craft) . AODS will estimate the following state 
parameters: 

Six parameters of the orbital state (target) 
(position and velocity) 

Atmospneric drag coefficient, C D 

- Coefficients of the frequency model for one- 
way TDRS System (TDRSS) data 

AODS will process the following types of observa- 
tion data: 

One-way TDRSS range and Doppler 

Two-way TDRSS range and Doppler 

Hybrid TDRSS range and Doppler 

One-way Scandard Ranging Equipment (SRE) range 
and range-rate 

Two-way SRE range and range-rate 
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2,1.2 INPUT REQUIREMENTS 

The ADDS input requirements are ao follows; 

• ADDS will accept input messaged containing data, 
executable code, and control commands. 

m ADDS input data will consist of the following; 

- Raw observation message3--Theso messages are 
sets of raw observations in the universal 
tracking data format. One observation set 
consists of a maximum of 100 observations 
(pairs of range and Doppler measurements) that 
were taken during the same spacecraft pass or 
contact. 

- New TORS vectors--These data include one state 
vector (position and velocity) for each active 
TDRS, up to three TDRSs. New TDRS vectors 
will be uplinked at least once per day. 

Maneuver schedule--This schedule specifies the 
predicted states and times of user spacecraft 
and/or TDRS maneuvers. It covers up to 
16 maneuvers and will be uplinked as neces- 
sary. The entire maneuver schedule will oe 
uplinked at the same time. 

Tracking schedule--This schedule is the track- 
ing schedule for the prediction of one-way 
Doppler observations. It covers 16 tracking 
intervals and will be uplinked as necessary. 
The entire tracking schedule will be uplinked 
at the same time. 

Initialization table--This table specifies the 
initial conditions for the estimator,, includ- 
ing the a priori state vector, which will be 
propagated for output until a solution is 
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reached. This table will be uplinked at the 
start of AODS execution and then later at the 
user's discretion. 

Constants — These constants, which will be used 
throughout the AODS processes, may have to be 
changed during long-term operations. They are 
categorized as follows : integration, conver- 

sion, and physical constants; station posi- 
tions (20 stations) and observation modeling 
constants; geopotential model constants; at- 
mospheric drag model constants; and timing 
coe.f iicients. 

Estimation control parameters--This set of 
parameters (e.g., maximum iterations, observa- 
tion weights, convergence criteria) provides 
control in estimating the spacecraft state. 

It will be uplinked at the first estimation 
process and then later at the user's discre- 
tion. 

• AODS will recognize the following control commands: 
REBOOT- -Reboot AODS. 

ABORT — Abort AODS processing; output activity 
log; do not destroy code. 

STOP--Terminate AODS processing in a normal 
manner; do not accept more data. 

START' — Start AODS processing? accept all 
data. (This is a reply to commands STOP and 
ABORT. ) 

SUSPEND-~Suspend oroit determination process? 
continue accepting data. 
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CONTINUE- -Resume orbit determination computa- 
tions. (This is a reply to command SUSPEND.) 

- STATUS REQUEST- -Output activity log. 

SET CLOCK--Set system clock to new time. 

c AODS will accept and load a partition of executable 
code. 

2.1.3 OUTPUT REQUIREMENTS 

The AODS output requirements are as follows: 

• AODS will periodically output an activity log con- 
taining a history of all activities that nave been 
performed by AODS. 

• AODS will output priority messages to request spe- 
cial ground support such as error handling, fast- 
timing, and so forth. 

m AODS will output tables of. predicted state vectors 
to the main onboard computer for experimental data 
annotation and direct downlink. 

• AODS will output predicted one-way Doppler observa- 
tions on a scheduled basis to the main onboard com- 
puter for receiver acquisition. 

c AODS will output the following reports from the 
estimator : 

DC Residuals Report--This report contains in- 
formation about each individual observation 
(e.g., tracking configuration, ooservation 
residual, editing) . 

DC Summary and Statistics Report--This report 
contains differential correction (DC) summary 
information (e.g., state update, new state, 
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standard deviations of state parameters) and 
DC statistics (e.g., current root-mean-square 
(rms) , previous rms, batch editing statistics) . 

2.2 SYSTEM PERFORMANCE REQUIREMENTS AND LIMITATIONS 
DEFINITION 

This section specifies those requirements that deal with 
system performance and the limitations associated with it. 
Section 2.2.1 presents the system performance requirements 
that define the schedules on which specific requirements 
must be satisfied. Section 2.2.2 presents the hardware and 
software requirements and the limitations that will affect 
AODS performance. 

2.2.1 SYSTEM PERFORMANCE REQUIREMENTS 

The system performance requirements for AODS are as follows; 

• AODS will capture all incoming messages upon demand. 

• AODS will service each control command immediately 
after reception. 

• AODS will maintain an activity log and output 
(downlink) it on a scheduled basis or when re- 
quested by a control command. 

• AODS will output a table of predicted user space- 
craft state vectors over a specified time interval 
at a specified frequency. For example, if the time 
interval is 1/2 hour and the frequency is 1 minute, 
the state vector predict tables will be generated 
as follows: 

Each time a hew solution is reached or a new a 

priori state vector (initialization table) is 

received, a table containing state vectors at 

1-minute intervals starting at the current 

time (t ) and ending 1 hour later (t + 1) 
n' n 

will be -generated and output. 
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Then, 1/2 hour later (t + 1/2) , the next 
table will be generated and output. This 
table will contain state vectors at 1-minute 
intervals over the next 1/2 hour. The start 
time of this table will be the end time of the 
previous table (t + 1) , and the end time 
will be 1/2 hour after that (t n + 1-1/2) . 

- The second step will be repeated until a new 
solution is reached or a new a priori state 
vector is received, which causes the process 
to begin again with the first step. 

AODS will output one-way Doppler observations no 
later than 1 minute before tne start time of tne 
current tracking interval. The actual amount of 
lead time will oe set by the ground control. 

AODS will complete data preprocessing and estima- 
tion on each batch of data oy tne time the next 
pass of raw observations is received. Since obser- 
vation data will be transmitted (uplinked) every 
revolution under normal circumstances, tnis proc- 
essing time will be limited to the lengtn of 
one revolution of the user spacecraft (nominally, 

90 minutes) . 

AODS will be capable of performing batch estimation 
over a user-specified time span, which will never 
be larger than 50 hours. In addition, AODS must be 
capable of handling a maximum of 500 observations 
in each batch of data. 

AODS will be capable of generating two types of 
reports during differential correction: 

The DC Residuals Report, if generated, will be 
generated either (1) after the first and last 



iterations on each batch of data or (2) after 
the last iteration on’ each batch of data. 

- The DC Summary and Statistics Report, if gen- 
erated, will be generated either (1) after the 
last iteration on each batch of data or 
(2) after every DC iteration. 

2.2.2 HARDWARE AND SOFTWARE REQUIREMENTS AND LIMITATIONS 

The AODS hardware and software requirements and the limita- 
tions associated with them are as follows: 

• The development computer will be STL's PDP-11/70 
under the RSX-11M operating system. 

• The target computer will be an LSI-11/23 under the 
RSX-11S operating system. It will have 256K bytes 
of random-access memory (RAM) , No peripherals will 
be available. 

• All necessary system software (i.e., the device 
handlers) in both the development and target com- 
puters will be available. 

• Since there will be no peripherals in the target 
system, all data must be managed in RAM. In addi- 
tion, overlaying of tasks is impossible. 

• Since the prototype AODS could lead tc onboard and 
ground-based experimental systems, an effort should 
be made during design to separate the general func- 
tions (i.e., those which could be used ;n both sys- 
tems) from the specific functions (i.e., those 
which apply only to the onboard application) . This 
may cause these systems to execute more slowly than 
if they were coded for one specific application. 
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2.3 FUNCTIONAL REQUIREMENTS DEFINITION 

This section specifies the AODS functional requirements, 
i.e., the functions that the system must perform to satisfy 
the system requirements and the performance requirements. 
Theca functional requirements are the most detailed require 
ments presented in this document. For further clarifica- 
tion, this section includes the functional model of AODS, 
i.e., the functional decomposition of the functional 
requirements and the corresponding data flow diagrams. In 
addition, the section contains two requirements maps to dem 
onstrate that the functional model of AODS satisfies all 
AODS functional requirements and, conversely, that the func 
tional requirements are complete. 

2.3.1 FUNCTIONAL REQUIREMENTS 

The AODS functional requirements specified in this section 
are presented according to functional areas, as follows: 

• System control (Section 2. 3.1.1) 

® Input processing (Section 2. 3. 1.2) 
c Data preprocessing (Section 2. 3. 1.3) 

• Data management (Section 2. 3. 1.4) 

Estimation (Section 2.3. l.b) 

• One-way Doppler prediction (Section 2. 3. 1.6) 

• Output processing (Section 2. 3. 1.7) 

These functional requirements are the most detailed require 
ments presented in this document. However, no attempt is 
made to define computational models or algorithms in this 
section, except where the requirements are specifically af- 
fected. The models are specified in Section 2.4. 

The functional requirements specified in Sections 2. 3. 1.1 
through 2. 3. 1.7 are numbered for later reference and re- 
quirements mapping. In the numbering system used, R indi- 
cates requirements and P indicates process. 
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1.1 System Control Functional Requirements 
functional requirements for system control are as fol- 

AODS will maintain an activity log containing the 
following: system events, informative messages, 

error messages, directives, and control commands. 

AODS will service each control command immediately 
upon reception. 

AODS will schedule maneuver recovery according to 
clock time and the maneuver schedule. 

AODS maneuver recovery will consist of the follow- 
ing : 

Rl.4.1 TORS maneuver--The predicted state after 
the maneuver will be given to the data 
preprocessor to be used for future gener- 
ation of the TDRS orbit file. 

Rl.4.2 User spacecraft marieuver--The TDRS orbit: 
files and the observation file will be 
purged. The startup procedure will oa 
performed; estimation will be resumed 
only when a complete estimation span of 
data has been received. 

AODS will schedule one-way Doppler prediction a 
user-specified number of minutes before the start 
time of eacn tracking interval in the tracking 
schedule. 

AODS will schedule the output of data and messages. 

Rl.6.1 AODS will schedule the output of severe 
errors from wnich the system cannot re- 
cover. 
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Rl.6,2 AODS will schedule the output of priority 
messages. 

Rl.6.3 AODS will schedule the output of the ac- 
tivity log at a specified interval. 

Rl.6.4 AODS will schedule the output of the ac- 
tivity log when specifically requested 
through a control command. 

Rl.6.5 AODS will scnedule the output of the pre- 
dicted one-way Doppler observations at 
least 1 minute before the time tag of the 
first observation. 

R1.7 AODS will schedule the generation and output of the 
state vector predict table at the end of the speci- 
fied interval after the last time of output. 

Rl.8 AODS will schedule the generation and output of the 
state vector predict table immediately after a new 
solution is' obtained. 

R1.9 AODS will schedule input processing wnen the input 
queue is full or when the input queue contains data 
and the system is otherwise idle. 

R1.10 AODS will schedule data preprocessing when a com- 
plete pass of data has been processed tnrougn input 
and estimation on the previous batcn has been com- 
pleted. 

Rl.ll AODS will schedule data preprocessing when a TDRS 
maneuver occurs or when a new TDRS vector has been 
received. 

R1.12 AODS will schedule estimation when a new pass of 
data has been added to the observations data set. 

R1.13 AODS will notify ground control when it nas an ex- 
cessive amount of idle time for fast timing. 
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2. 3. 1.2 Input Processing Functional Requirements 

The functional requirements for input processing are as fol- 
lows : 

R2.1 AODS will capture all incoming messages upon demand. 

R2.2 AODS will accept as input messages containing data, 
control commands, and executable code. 

R2.3 AODS will process the following types of input 

data: raw observation messages, new TDRS vectors, 

maneuver schedule, tracking schedule, initializa- 
tion table, estimation control parameters, and con- 
stants (i.e., miscellaneous constants, station 
constants, geopotential tables, atmospheric density 
tables, and timing coefficients) . 

i 

R2.4 AODS will accept the following control commands: 
REBOOT, ABORT, STOP, START, SUSPEND, CONTINUE, 

STATUS REQUEST, and SET CLOCK. 

R2.5 AODS will accept as input a partition of executable 
code. 

R2.6 AODS will load a partition of executable code into 
RAM. 

R2.7 AODS will extract the usable bytes from eacn raw 
observation message to form reduced observations 
and queue them by type. 

2.3. 1.3 Data Preprocessing Functional Requirements 

The functional requirements for data preprocessing are as 

follows : 

•> 

R3.1 AODS will accept only those observations (raw 

tracking data) which have the proper tracking con- 
figuration. 
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R3.2 


R3.3 

R3.4 

R3.5 

R3.6 

R3.7 

2.3. 

The 

lows 

R4.1 

R4.2 

R4.3 

R4.4 


♦ 


AODS will convert the observation measurements and 
time tag to the correct engineering units. 

No smootning of the raw observation data will be 
performed. 

AODS will pregenerate TDRS oroit files from the 
uplinked TDRS vectors (one file for each TDRS) . 
These files will cover the same time 3pan as the 
observation file; they will be used iteratively by 
the batch estimator. 

AODS will update the TDRS orbit files when a new 
TDRS vector is received. 

After a TDRS maneuver, AODS will use tne predicted 
state vector as the base vector for generating the 
TDRS orbit file in the future. 

After receiving an update to a TDRS maneuver, AODS 
will update the appropriate TDRS orbit file from 
the maneuver time to the current processing time by 
propagating the input TDRS vector. 

1,4 Data Management Functional Requirements 

functional requirements for data management are as fol- 

AODS will manage all data files in memory, since no 
peripherals will be provided. 

AODS will have tne capability to locate, read, and 
write observation records in the observation file. 

AODS will have the capability to locate, read, 
v; rite, and update the records of the TDRS orbit 
files. 

AODS will have tne capability to purge all data 
files . 
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2. 3. 1. 5 Estimation Functional Requirements 

The functional requirements for estimation are as follows: 

R5.1 AODS will perform differential correction on the 
most recent fixed-length span (specified through 
control parameters) of observation data. 

R5.2 The method of estimation will be batch least- 
squares. 

R5.3 Due to the real-time processing of AODS, the esti- 
mation time span will be slid forward to encompass 
each new pass of observation data. This wil?* oe 
referred to as a "sliding batch estimator." 

R5.4 During initialization of the estimation process 

(which is defined as operations included in estima- 
tion using a particular batch of data) , the follow- 
ing will be performed: 

R5.4.1 AODS will initialize the estimation pa- 
rameters from the initialization table 
and/or the estimation control parameters 
if either was received since the begin- 
ning of the previous estimation process. 

R5.4.2 AODS will set up the new estimation span, 

R5.5 Initialization of the estimation parameters will be 
performed after estimation has been suspended 
through a control command. 

R5.6 AODS will model the following types of observa- 
tions: one-w*Sf TDRSS range and Doppler? two-way 

TDRSS range and Doppler; hybrid TDRSS range and 
Doppler; one-way SRE range ar.d range-rate? and two- 
way SRE range and range-rate. 

R5.6.1 AODS will resolve the range ambiguity 
during observation modeling. 
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R5.7 AODS will perform n 3igrna editing during estimation. 

R5.8 AODS will test for convergence at the end of each 

iteration in the estimator. 

R5.8.1 AODS will declare a new state solution at 
the point of convergence. 

R5.8.2 AODS will stop estimation when the maxi- 
mum iteration is reacned, if convergence 
is never found. 

R5.9 AODS will be capable of generating a DC Summary and 
Statistics Report. This report, if generated, will 
be generated and output either (1) after every 
iteration or (2) after the last Iteration on each 
batch. 

R5.10 AODS will be capable of generating a DC Residuals 
Report. This report, if generated, will be gener- 
ated and output either (1) after the first and last 
iterations on each batsn or (2) after the last 
iteration on each batch. 

2 . 3 . 1 . 6 One-Way Doppler Prediction Functional Requirements 

The functional requirements for one-way Doppler prediction 

are as follows: 

R6.1 AODS will predict (simulate) one-way Doppler ob- 
servations over the time spans indicated by the 
uplinked tracking schedule. 

R6.2 AODS will use the TDRS, whose ID will be specified 
with each tracking interval, to predict the one-way 
Doppler observations. 

R6.3 No observation feasioility checking will be per- 
formed, since the tracking schedule will contain 
valid intervals for tne specified TDRS. 
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R6.4 The target (user spacecraft) state vector used in 
one-way Doppler prediction will be based on the 
moot recent state solution. In the case in which a 
user spacecraft maneuver occurred or a new initial- 
ization table was received, the most recent solu- 
tion will be overridden by the new a priori 
estimate, 

R6.5 The TORS state vector used in one-way Doppler pre- 
diction will be based on the TORS vector used to 
generate the TORS orbit file. 

2 . 3 . 1 . 7 Output Processing Functional Requirements 

The functional requirements for output processing are as 

follows : 

R7, 1 AODS will generate and output the state vector pre- 
dict table. This table will be based on the most 
recent state solution. In the case in which a user 
spacecraft maneuver has occurred or a new initiali- 
zation taole has been received, the most recent 
solution will be overridden by the new a priori 
state vector. 

R7.2 AODS will output priority messages directly to the 
ground control, 

R7.3 AODS will output the activity log. 

R7.4 AODS will output the predicted one-way Doppler ob- 

servations. 

R7.5 AODS will output the DC Residual Reports as they 
are generated by the estimator. 

R7.6 AODS will output the DC Summary and Statistics 
Reports as they are generated by the estimator. 
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2.3,2 AODS FUNCTIONAL MODEL 


The functional model of AODS io composed of three parts: a 

functional decomposition of the system, the associated data 
flow diagrams, and a data dictionary. This section provides 
the AODS functional decomposition and data flow diagrams 
(DFDs) . For the convenience of the reader, Appendix a con- 
tains the data dictionary, 

The AODS functional decomposition shows the functional 
breakdown of each major process. The DFDs 3how the inter- 
faces between processes (data flows) , data stores, and data 
sources and sinks. Appendix A specifies the ground rules 
for DFDs. Tne data dictionary makes tnis model rigorous by 
defining each data element show; in the DFDs, 

Figure 2-2 shows the top level of AODS. Figures 2-3 through 
2-14 show the next two levels of detail. An asterisk by an 
item in any of the diagrams indicates that that item appears 
more than once. in that DFD . Following the figures is the 
functional decomposition of AODS. A description of each 
process i3 provided and numbered according to the data flow 
diagrams. These descriptions are organized according to the 
seven processes specified in the top-level diagram (Fig- 
ure 2-2) . 

The functional decomposition of the AODS is provided below. 
The processes are as follows; 

PI Control AODS by monitoring system activity, sched- 

uling by clock time, and satisfying ground commands, 

Pl.l Issue ground control requests, which are dictated 
by the highest priority command in the commands 
queue. 

PI. 2 Monitor system status to determine the next action, 
which is dictated by normal or abnormal execution. 
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Figure 2-4. Process. 2: Input Processing 
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Figure 2-6. Process 4: Data Management 
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Figure 2-7. Process 4.1; TDRS Orbit File Management 






Figure 2-9. Process 5: Estimation 
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Figure 2-14. Process 7: Output Processing 




PI. 3 Schedule maneuver recovery and one-way Doppler pre- 
diction according to clock time and the maneuver 
and tracking schedules, respectively. 

PI. 4 Determine the next action based on the nigheot 

priority of the ground control, time-scheduled, and 
execution requests. 

PI. 5 Generate the directives that will cause the action 
to be executed. 

P2 Receive input messages, extract and queue useful 

observation data, store the other data, and load 
program partitions into RAM. 

P2.1 Capture and queue all input messages and send con- 
trol commands to system control. 

P2.2 Decode and identify the input messages, 

P2.3 Load a partition of executable code into RAM. 

P2.4 Identify and store the input data in the proper 
data sets. 

P2.5 Extract the usaole portions of the raw observation 
message and store this input observation in the 
proper queue based on ooservation type. 

P3 Prepare the observation data for later use and 

propagate the TDRS vectors over the observation 
time span. Update the TDRS orbit files when a new 
TDRS vector is input. 

P3.1 Determine whether each observation has the proper 
tracking configuration. 

P3.2 Change the values to engineering units and set 

switches that will indicate tne observation's at- 
tributes . 
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P3.3 


P3.4 

P4 

P4.1 


P4.2 


P4.3 

P5 


P5. 1 


Update a TDRS orbit file to reflect the new TDRS 
vector as follows: retrieve the next TDRS record 

(sequential order), propagate the new TDRS vector 
to the time tag, replace the TDRS state, and re- 
write the record. 

Generate TDRS vectors to cover the time span of the 
new pass of observation data. 

Manage the TDRS orbit files and the observation 
file. 

Manage the TDRS orbit files. 

P4.1.1 Locate the next empty TDRS record. 

P4.1.2 Write a TDRS record in memory. 

P4.1.3 Locate the TDRS record to be updated. 

P4.1.4 Locate the record containing the TDRS 

request time. 

P4.1.5 Read a TDRS record from memory. 

Manage the observation file. 

P4.2.1 Locate the next observation record in 
memory. 

P4.2.2 Write an observation record in memory. 
P4.2.3 Read an observation record from memory. 
Purge all files. 

Estimate the state solve-for parameters based on 
the statistics gathered from the observed and com- 
puted observation data. 

Initialize the estimation process by updating the 
solve-for parameters from the initialization table 
and reinitializing switches. 
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P5.1.1 Update the estimation parameters from the 
initialization table and estimation con- 
trol parameters, if required. 

P5.1.2 Compute the start and end times of the 
new estimation time span. 

P5.1.3 Move epoch to the end time of the estima- 
tion time span. 

P5.1.4 Perform the necessary housekeeping after 
a user spacecraft maneuver. 

P5.2 Accumulate statistics from the computed and ob- 
served measurements and the current state. 

P5.2.1 Obtain the next observation and extract 
the time tag. 

P5.2.2 Propagate the target state vector to the 
observation time. 

P5.2.3 Compute the observations based on the 

current state at the observation time and 
the partial derivatives of the observa- 
tion with respect to the state parameters. 

P5.2.4 Compute and accumulate the normal matrix 
and normal equation and perform n sigma 
editing. 

P5.3 Solve the normal equations to obtain the state cor- 

rection vector. 

P5.4 Update the state parameters witn the state correc- 

tion vector. 

P5.5 Test tne state and correction vectors for conver- 
gence . 



P5.6 Generate estimation reports. 

P5.6.1 Generate a residual report line by line 
as observations are computed. 

P5.6.2 Generate the DC Summary and Statistics 
Report at the end of each iteration. 

P6 Predict the one-way Doppler observation over a 

specified tracking span at a specified time inter- 
val. 

P6.1 Schedule observations according to the tracking 

schedule. 

P6.2 Propagate the TDRS state vector to the scheduled 
time. 

P6.3 Propagate the target spacecraft state vector (based 

on the most recent solution) to the scheduled time. 

P6.4 Compute the observation at the scheduled time based 
on the TDRS and target state vectors. 

P7 Propagate the target state vector for output; pre- 

pare and send the output messages for reports, 
data, and error messages. 

P7.1 Encode an error message into an output message. 

P7.2 Encode a line of a report into an output message. 

P7.3 Encode a piece of data into an output message. 

P7.4 Generate the state vector predict table. 

P7.5 Send the output messages to the onboard computer 

(OBC) . 

2.3.3 REQUIREMENTS MAPS 

This section presents two requirements maps that demonstrate 
that the functional model of AODS satisfies all AODS func- 
tional requirements, and, conversely, that the functional 
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requirements are complete. Table 2-1, the functional re- 
quirement/process map, shows which processes (in the func- 
tional model) satisfy each functional requirement. 

Table 2-2, the process/functional requirement map, shows 
which functional requirements are satisfied by each process 
in the model. Model completeness is demonstrated when each 
requirement is paired with at least one process, and vice 
versa. 

2.4 FUNCTIONAL SPECIFICATIONS 

This section presents the functional specifications for 
AODS . These specifications include computational models, 
algorithms, and procedures to be used in satisfying the 
functional requirements. There is not a one-to-one corre- 
spondence between the specifications and the requirements. 
However, the specifications have been grouped into the same 
functional areas as the functional requirements in Sec- 
tion 2.3.1. In cases in wnich a mathematical model is spec 
ified, the reference in which the algorithm can be found is 
cited rather than including the matnematics here. Those 
computational models that have not been specified to date 
are marked with the letters TBD, for "to be determined." 
These models will be specified through the GSFC Assistant 
Technical Representatives for the Microprocessor Software 
Support task. 

2.4.1 SYSTEM CONTROL FUNCTIONAL SPECIFICATIONS 

The functional specifications for system control are as fol 
lows : 

© Perform the following functions in order of prior- 
ity (the functions are listed according to their 
priority, with the highest priority first) : 

Capture input messages. 

Service control commands as indicated in 
Table 2-3. 
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Table 2-1. Functional Requirement/Process Map 


REQUIREMENT 

NUMBER 

PROCESS NUMBER 

REQUIREMENT 

NUMBER 

PROCESS NUMBER 

R1 

PI 

R3.6 

P3.3 

R1.1 

P1.2,P1.3,P'/.4 

R3.7 

P3.3 

R1.2 

P1.1# P1.4, PI. 5 

R4 

P4 

R1.3 

PI, 3 

R4.1 

P4.1, P4.2, P4.3 

R1.4 

PI. 3, PI ,4, PI. 5, P2,3, 

R4.2 

P4.2.1, P4.2.2, P4.2.3 


P6.1 

R4.3 

P4,1,2, P4.1.1, P4.1.3, 

Rl.4,1 

PI, 3, P3.3 


P4.1.4, P4.1.5 

R 1,4,2 

P1.3, P5,1 ,4 

R4.4 

P4,3 

R1.5 

PI *3, PI. 4, PI. 6 

R5 

P5 

R1.6 

PI, 2, PI, 3, PI, 4, P1,5 

R5.1 

P5.2, PS.3, P6.4, P5.6, 

R 1,6.1 

PI, 2, PI, 4, PI, 6 


P6.6, P5,2,1, P5.2.2 

R 1.6.2 

PI, 4, PI, 5 

R5.2 

P5.2, P5,3, P5.2.1, | 

P5.2.2 

R 1.6.3 

PI. 3, PI. 4, PI. 5 

R6.3 

P5.1.2, P6.1.3 

R 1.6,4 

P1*1, ?\ A, P13 

R5.4 

P5.1 

R 1.6.6 

P1,3 f PI, 4, PI, 6 

R6.4.1 

PB.1,1 

R1.7 

PI. 3, PI *4, P1.5 

R6.4.2 

P5.1.2, P6.1.3 

R1.8 

PI, 2,, PI, 4, PI ,6 

R5.6 

P5,1,1, P5,1,2, P5.1.3 

R1.9 

PI, 2, P'1,4, PI, 5 

R6,6 

P6.2.3 

R1.10 

PI. 2, PI, 4, PI. 6 

R6.6.1 

P5.2.3 

R1.11 

PI, 2, PI, 3, PI, 4, PI .5 

R5.7 

P5.2.4 

R1.12 

PI, 2, PI. 4, PI, 5 

R6.8 

P5.6 

R1.13 

PI, 2, PI. 4, PI .6 

R6.8.1 

P6.5 

PI. 14 

PI, 4, PI. 5 

R5.8.2 

P5.5 

R2 

P2 

R5.9 

P5.6.2, P5.5 

R2.1 

P2.1 

R5.10 

P5.6.1, P5.6 

R2 2 

P2,2 

R6 

P6 

R2.3 

P2.2, P2,4 

R6.1 

P6.1, P6.2, P6.3.P6.4 

R2.4 

P2.1 

R6.2 

P6.2 

R2.5 

P2,2 

R6.3 

P6.1 

R2.6 

P2.3 

R6.4 

P6.3 

R2.7 

P2.5 

R6.6 

P6.2 

R3 

P3 

R7 

P7 

R3.1 

P3.1 

R7.1 

P7.4, P7.3, P7.5 

R3,2 

P3.2 

R7.2 

P7.1, P7.5 

R3.3 

P3.1 , P3.2 

R7.3 

P7.2, P7.5 

R3.4 

P3.3, P3,4, P4.1.1 
P4.1.2 

R7.4 

P7.3, P7.5 

R3.5 

P3.3 

R7.5 

P7.2, P7.5 



R7.6 

P7.2, P7.5 
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Table 2-2. Process/Functional Requirement Map 


PROCESS 

REQUIREMENT 

PROCESS 

REQUIREMENT 

NUMBER 

NUMBER 

NUMBER 

NUMBER 

PI 

R1 

P4.2 

R4.1 

P1.1 

R1.2, R 1,6,4 

P4.2.1 

R4,2 

PI, 2 

R1.1. R1.6, R1.6.1, 

P4.2.2 

R4.2 


R1.8, R1,9,R1,10, 

R 1*1 1 # R1.12, R 1.13 

P4.2.3 

R4.2 

PI, 3 

R1.1 , R1.3, R1,4, 

P4.3 

R4.1, R4.4 


R1.4.1, R1,4,2 f R1,5, 

P5 

RB 


R1,6,R1.6.3, Rl.6,5, 
R1.7, R1.11 

P6.1 

R1.4, RB.4 

PI, 4 

Rltlf R1.2, R1.4, 

PS, 1,1 

R5.4.1 


R1.B, R1,6, R1.6.1 , 

P5.1 ,2 

R6.3, RB.4.2 


R1.6.2, R1,6,3, 

R 1.8.4, R 1.6,5, R1,7, 

PB.1,3 

R5,3, RB.4, 2 


R1,8, R1*9, R1.10, 
R1.11, R1.12, R1.13, 
R1.14 

PB.1.4 

R 1.4.2 


P52 

R5.1, R5.2 

P1,B 

R1*2, R1.4, R1.6, 

**3.2,1 

R6.1.R6.2 


R1.6, R 1,6,1, R 1,6.2, 

PB.2,2 

R5.1, RB,2 


R1,6,3, R 1,6,4, 
Rl.6,5, R1.7, R1.8, 

PB.2,3 

R6.6, RB.6.1 


R1.9, R1.10, R1.11, 

P5.2.4 

R5,7 


R1.12, R1.13, R1.14 

P5.3 

RB.1, RB,2 

P2 

R2 

PB.4 

RB.1 

P2.1 

R2.1, R2.4 

PB.5 

RB.1 , RB.8, R5.8.1, 

P2.2 

R2.2, R2.3, R2.5 


RB.8.2, R5.9 

P2.3 

Rt.4, R2.6 

P5,6 

R6.1 

P2.4 

R2.3 

PB.6.1 

R6.10 

P2.5 

R2,7 

PB.6,2 

RB.9 

P3 

R3 

P6 

R6 

P3.1 

R3.1, R3.3 

P6.1 

R6.1, R6.3 

P3.2 

R3,2, R3.3 

P6,2 

R6.1, R6,2, R6.5 

P3.3 

R1.4.1, R3,4, R3.5, 

P6.3 

R6.1 , R6,4 


R3.6, R3.7 

P6.4 

R6,1 

P3,4 

R3.4 

P7 

R7 

P4 

R4 

P7.1 

R7.2 

P4.1 

R4,1 

P7.2 

R7.3, R7.5, R7.6 

P4.1.1 

R3.4, R4.1 , R4.3 

P7.3 

R7.1, R7.4 

P4.1.2 

R3.4, R4.3 

P7.4 

R7.1 

P4.1.3 

R4.3 

P7.5 

R7.1 , R7.2 r R7.3, 
R7.4, R7.5, R7.6 

P4.1.4 

R4.3 


P4,1,5 

R4.3 
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Output severe error messages. 

Perform the next time-scheduled function of 
the following: predict one-way Doppler obser- 

vations; output one-way Doppler observations; 
predict and output state vector table; perform 
maneuver recovery; output activity log. 

Process input messages. 

Update TDRS files with new TDRS vector. 
Preprocess data. 

Perform estimation. 

Notify ground control of excessive idle time. 

» Enter every system status message received from the 
other processes, every command received from ground 
control, and every directive generated into the 
activity log. 

« Never perform data preprocessing if estimation is 
in progress. 

2.4.2 INPUT PROCESSING FUNCTIONAL SPECIFICATIONS 

The functional specifications for input processing are as 
follows : 


• Identify and decode all input messages according to 
the input message formats specified in Appendix C. 

• Accept as input a partition of executable code and 
load it into RAM. (The method is TBD. ) 

• Extract the usable bytes of each raw observation 
message and change binary numbers to real numbers 
where necessary (see Section C.1.2 in Appendix C) . 



• Queue the observations in the following manner: 

- Queue each observation type (one-way, two-way, 
and so forth) separately. 

Within each observation type, queue the obser- 
vations as they are received (in ascending 
time order) . 

2.4.3 DATA PREPROCESSING FUNCTIONAL SPECIFICATIONS 

The functional specifications for data preprocessing are as 
follows : 

• Check each observation for the proper tracking con- 
figuration by testing the following parts of the 
input ooservation: 

Tracker type (TDRSS or SRE) 

User support identification code (SIC) 

Vehicle identification code (VID) 

Ground antenna IDs (forward and return) 

TDRS IDs (forward and return) 

• Check each observation further for acceptability by 
testing the following: 

Time tag 

Valid/invalid switches for range and Doppler 

• Make the following computational modifications to 
each acceptable observation: 

Convert the time tag from year, seconds of 
year, and microseconds of second to a modified 
Julian date in universal time clock (UTC) time. 

Modify the TDRSS range and Doppler measure- 
ments using the raw data reduction algorithms 
given in Reference 2. 
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- Compute the SRE range and range-rate measure- 
ments using the raw data reduction algorithms 
given in Reference 3. 

Propagate the TORS using the following: 

- Integrator: Eighth-order predictor/corrector 

with fourth-order Runge-Kutta starter (Refer- 
ence 4) 

- Method: Cowell fixed-step (Reference 4) 

- Force models for TDRS state: 

Up to 15-by-15 geopotential field (Refer- 
ence 4) 

Solar radiation pressure (Reference 4) 

Solar and lunar gravitational effects 
(analytic) (TBD) 

Central body; Eartn (Reference 4) 

Special feature: Integration will be per- 

formed over full steps only. The propagator 
will interpolate for points that fall between 
steps. (The method of interpolation is TBD.) 

When a new TDRS vector is received, update tne TDRS 
orbit file by propagating the new vector over the 
time span covered by the current file and replacing 
the records with the new vectors at the same time 
tags. 

When a TDRS maneuver occurs, update the TDRS inte- 
gration start data by propagating che predicted 
TDRS state vector to the time tag of the TDRS inte- 
gration start data and replacing it. 
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2.4.4 DATA MANAGEMENT FUNCTIONAL SPECIFICATIONS 

The functional specifications for data management are as 

follows: 

• Manage one observation file and three TDRS orbit 
files in memory. 

• Locate, read, and write observation records in a 
sequential manner. 

• Write TDRS orbit records in a sequential manner. 

• Read TDRS records keyed by time. 

• Update (i.e., read and then replace) TDRS records 
in a sequential manner. 

• Create and manage all files such that records may 
be deleted and added without changing the size of 
the files. 

2.4.5 ESTIMATION FUNCTIONAL SPECIFICATIONS 

The functional specifications for estimation are as follows: 

• Perform differential correction on the most recent 
batch of observation data (fixed-length time span) 
using the following: 

- Method: Batch least-squares (Reference 4) 

Procedure: Sliding batch estimator --Each time 

a new pass of data is received, perform the 
following : 

Move the epoch to the end time of the new 
pass . 

Determine the start time of tne estima- 
tion span by counting back the specified 
amount of time from epoch. 
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Process the observation data in reverse 
order (descending time) . 


Update the 3tate at epoch at the end of 
each iteration. 

Test for convergence at the end of each 
iteration. (The method is TBD. ) 

Generate DC Residuals Reports and DC Sum- 
mary and Statistics Reports as specified 
by control parameters. 

Stop estimation when convergence, diver- 
gence, or the maximum iteration is 
reached. 

- Restrictions: 

Do not begin estimation until the minimum 
time span of data has been received. 

Do not perform estimation wnenever the 
observation data span is less tnan the 
estimation time span. 

• Propagate the user spacecraft (target) state and 
state transition matrix using tne following: 

- Integrator: Eignth-order predictor/corrector 
with a fourth-order Runge-Kutta starter (Ref- 
erence 4) 

Method: Cowell fixed-step 

Force models for spacecraft state: 

Up to 15rby-15 geopotential model (Refer- 
ence 4) 

Atmospheric drag (Harris-Priester) (Ref- 
erence 4) 
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Solar and lunar gravitational effects 
(analytic) (TBD) 

Central body; Earth (Reference 4) 

- Force models for the state transition matrix 

(10 solve-for parameters) ; J 2 , j 3 , j 4 , 

and drag (integrating variational equations) 
(method of integration is TBD) 

- Special feature; Integration will be per- 
formed over full steps only. The propagator 
will interpolate for points that fall between 
steps. (The method of interpolation is TBD.) 

• Retrieve the TORS vectors required and interpolate 
to obtain the TDRS vector at the observation time. 

• Perform n sigma editing (Reference 4) . 

• Check for a new initialization table and/or estima- 
tion control parameters during initialization and 
after suspension (by ground control) of a batch 
estimation process. 

• Solve for the following state parameters: 

- Six parameters of the user spacecraft orbital 
state 

One atmospheric drag coefficient, C D (op- 
tional) 

- Three coefficients of the frequency model for 
one-way TDRSS data (optional) 

• Model the following types of observations: 

One-way TDRSS range and Doppler (Reference 3) 

Two-way TDRSS range and Doppler (References 3 
and 5) 

Three-way TDRSS range and Doppler (Reference 3) 
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One-way SRB range and range-rate (Reference 4) 
Two-way SRE range and range-rate (Reference 4) 


• Resolve range ambiguity during observation modeling 
(Reference 5) . 

• Correct for ionospheric refraction in the observa- 
tion model on option. (The method is TBD. ) 

• Compute the partial derivatives of the observations 
with respect to the following parameters: 

- User spacecraft orbital state (References 4 
and 5) 

- Atmospheric drag (References 3 and 4) 

Coefficients of frequency model for one-way 
TDRSS observations (Reference 3) 

2.4.6 ONE-WAY DOPPLER FUNCTIONAL SPECIFICATIONS 

The functional specifications for one-way Doppler prediction 
are as follows: 

• Predict one-way Doppler observations over the input 
tracking interval using the specified TDRS. 

• Retrieve the TDRS vector from the TDRS oroit file 
initially and tnen propagate it using tne models 
given in the data preprocessing specifications 
(Section 2.4.3) . 

• Propagate the most recent state solution to obtain 
the user spacecraft state vector. If a solution 
has not been reached after a new initialization 
table has been input, the a priori state (in the 
initialization table) will be used as tne reference 
vector for user spacecraft propagation. The propa- 
gation models given in the estimation specifica- 
tions (Section 2.4.5) will be used. 
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Do not check the scheduled observations for feasi- 
bility. 


2.4.7 OUTPUT PROCESSING FUNCTIONAL SPECIFICATIONS 

The functional specifications for output processing are as 
follows : 

• Output all information in the output message for- 
mats specified in Appendix C. 

• Generate a state vector predict table for the user 
spacecraft over a specified time interval, i, at a 
specified vector frequency, m minutes, as follows: 

Each time a new solution is reached or a new a 
priori state vector (initialization table) is 
received, a table containing state vectors at 
m-minute intervals starting at the current 
time (t n ) and ending two time intervals 
later (t + 2i) will be generated and output. 

Then, one time interval later (t + i) , the 
next table will be generated and output. This 
taole will contain state vectors at m-minute 
intervals over the next time interval. The 
start time of this table will be the end time 
of the previous table (t + 2i) , and the end 
time will be one time interval later (t n + 3i) . 

The second step will be repeated until a new 
solution is reacned or a new a priori state 
vector is received, which causes the process 
to begin again with the first step. 

• Propagate the user spacecraft using the models 
given in the estimation specifications (Sec- 
tion 2.4.5) . 
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S ACTION 3 - REQU I REMENTS ANALYSIS 


This section presents the analysis of the AODS require- 
ments. The AODS functional requirements were analyzed to 
determine the feasibility of implementing the system on an 
LSI-11/23 computer. Both the computer memory requirements 
and the AODS execution time requirements were determined. 

The timing requirements, which were defined through an ex- 
tensive timing study, were applied to the operational sce- 
nario in a throughput analysis to show the feasibility of 
performing a worst case scenario within the specified time. 
In addition, an error contigency plan was developed for tne 
operational scenario. 

Section 3.1 presents the operational scenario. Sec- 
tions 3.2, 3.3, and 3.4 present the timing and computer mem- 
ory studies, tne tnrougnput analysis,' and the error 
contingency plan, respectively. 

3.1 OPERATIONAL SCENARIO 

Tnis section presents the standard internal operational sce- 
nario for AODS, which includes startup operations, observa- 
tion data processing, and other processing. 

The startup operational scenario is as follows: 

1. The start command is uplinked. 

2. The following must be uplinked before the first 
pass of tracking data: 

0 Miscellaneous constants (optional) 

• Station constants (optiorfal) 

• New TDRS vectors 

3. The initialization table must oe uplinked to initi- 
ate the generation and output of state vector pre- 
dict taoles. 
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4. 1'he following must be uplinked to begin one-way 
Doppler prediction; 

• Initialization table 

• Tracking schedule 

• New TDRS vectors 

5. The maneuver schedule must be uplinKed before a 
maneuver will be scheduled. 

6. The following must be uplinked before estimation 
will begin: 

• Initialization table 

• Estimation control parameters 

• Raw tracking data 

7. The following data sets may be uplinKed when neces- 
sary througnout execution: 

o Initialization table 

• Estimation control parameters 

• Maneuver schedule 

• Tracking schedule 

• New TDRS vectors 

• Raw tracking data 

8. The following data sets may be uplinked when esti- 
mation is net in progress: 

• Station constants 

• Geopotential table 

• Atmospheric density table 

• Timing coefficients 

9. * A pass of tracking data is uplinKed according to 

one of tne following scenarios: 

• One burst of data containing one observation 
at the smallest interval 
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One burst of data containing all observations 
covering a specified time interval 




10. Data uplinking continues until the minimum estima- 
tion span is filled. 

When a complete batch of data (specified lengtn of time) has 
been received, AODS begins a standard operational procedure 
for each successive batch of data. This observation data 
processing scenario is as follows: 

1. The new pass of observation data is captured and 
queued for the data preprocessor. 

2. The new pass of data is preprocessed and written to 
the observation file. The TDRS vectors are propa- 
gated from tne end of the previous pass to the end 
of the current pass of data and written to the TDRS 
orbit files. 

3. Differential correction (DC) is performed on the 
next batch of data, which is determined by starting 
at the end time of tne ooservation file (epoch) and 
counting back the specified amount of time. If not 
enough data exist to cover the estimation span, DC 
will not be performed. 

4 . DC is controlled Dy the estimation control param- 
eters. DC reports are generated and output during 
estimation. 


5, When a solution is reached, a new state vector pre- 
dict table covering 1 hour in the future is gener- 
ated and output. 


6. If a solution is not reached by the maximum itera 
tion of the DC, estimation stops until the next: 
pass of data is received. 
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During the processing of observation data, other activities 
are being performed. The scenario for other processing is 
as follows; 

1. One-way Doppler observations are predicted based on 
the most recent state solution. Prediction is 
scheduled so that the observations will be ready 
for output at the specified pad time beCore the 
start time of the current tracking iterval. 

2. State vector predict tables of a user-specified 
lengtn continue to oe generated and output at a 
user-specified frequency. 

3. The activity log continues to be output at a speci- 
fied time interval. 

4. Priority (error) messages are output upon demand. 

5. Commands are serviced immediately after reception. 

6. All incoming data messages are captured and queued. 

7. The following types of input are processed; 

• Estimation control parameters 

• Initialization table 

• Tracking scnedule 

• Maneuver schedule 

• Mew TORS vectors 

• Observation data 

• Commands 

Other operations cannot be performed wnile estimation is 
active. The operations that are performed after estimation 
is completed on the current batch of data are as follows: 

1. The following types of input are processed: 

o Station constants 

• Geopotential tables 
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Drag tables 
Timing coefficients 
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2. The TDRS orbit file(s) ace updated witn the new 
TDRS vector (s) . 

3. TDRS maneuver recovery is performed. 

4. User spacecraft maneuver recovery is performed. 

5. The next pass of observation data is preprocessed. 
3.2 TIMING AND COMPUTER MEMORY STUDIES 

The objective of the timing and computer memory studies is 
to provide a basis for determining the timing and memory 
requirements of AODS . Tnis section presents both the con- 
tent of, and the results obtained from, these studies. 

3.2.1 TIMING STUDY 

The four activities necessary to determine the timing re- 
quirements for AODS are as follows: 

1. Obtain a comparison of the execution time of the 
PDP-11/70 and LSI-11/23 computers. 

2. Determine the actual time for eacn type of instruc- 
tion by running tests on the PDP-11/70. 

3. Time the existing pieces of software, wnich are 
similar to those required by AODS. 

4. Define a method for estimating execution time based 
on FORTRAN code. 

The results of this study are used during throughput analy- 
sis to estimate the timing reuqirments of the main functions 
in AODS. Due to the assumptions tnat were made in this 
study, a confidence level cannot be stated at this time. 
However, after a benchmark test is run cn STL's PDP-11/70 
and LSI-11/23 computers, the true LSI-to-PDP ratio will be 
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Known, and a level of confidence will be assigned to this 
study. 

3, 2. 1. 1 Comparison of PDP-11/70 and LSI-11/23 Timing 

AODS will be executed on two computers: the PDP-11/70 and 

the LSI-11/23. Because it must be demonstrated that the 
LSI-11/23 can perform the necessary computations within the 
time constraints, a comparison of execution times of the two 
computers is necessary. To obtain this comparison, the book 
values of the instruction times on both machines were ob- 
tained. Table 3-1 presents the instruction timing from the 
processor handbooks (References 6 and 7). The table spe- 
cifies the minimum, maximum, and typical instruction times 
for the PDP-11/70 and the minimum and maximum times for the 
LSI-11/23, all of which were taken from the handbooks. 
However, no typical time was specified in the handoooxs for 
the LSI-11/23, so the average time was computed and is used 
as the typical time for that computer. The ratio of' the LSI 
to the PDP was also computed for each instruction type. The 
ratios are large due to the special floating point package 
(FP-ll/C) in STL's PDP-11/70. 

Using only floating point values, it is estimated that AODS 
will consist of 60 percent load-and-compare (L&C) instruc- 
tions, 20 percent single-precision (SP) arithmetic instruc- 
tions, and 20 percent double-precision (DP) arithmetic 
instructions. Thus, using the average ratio of each of the 
instruction groups, the following equation represents the 
ratio of LSI-to-PDP execution time. 

Ratio LSI: PDP = 60% L&C + 20% SP + 20% DP 

= 0.6 (37.73) + 0.2 (49. 27) + 0.2 (76.58) 

= 47.8 

This ratio is used throughout the remaining timing studies 
and the throughput analysis as the relationship of the LSI 
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Table J-l. Comparison of PDP-11/70 and LSI-11/23 
Instruction Times 


INSTRUCTION® 

PDP-11/70 (WITH FP-1 1/Cl TIMES 
(p«) 

LSI-1 1/23 TIMES 
(Pll 

RATIO 

LShPDP 

MINIMUM 

MAXIMUM 

TYPICAL 

MINIMUM 

MAXIMUM 

AVERAGE 

LOAO-AND'COMPARE 








SP LOAD 

0.36 

0.36 

0.36 

9.15 

18,77 

13,96 

38,78 

DP LOAD 

0.36 

0.36 

0.36 

11,65 

22,08 

16,82 

46,72 

SP COMPARE 

0.54 

1.08 

0.81 

20.25 

29.57 

24.91 

30.75 

DP COMPARE 

0.64 

1.08 

0,81 

22,05 

34,08 

28,07 

34.66 

SP ARITHMETIC 








SP ADD 

0.9 

2.62 

0,96 

37.05 

96,77 

66,91 

70.43 

SP SUBTRACT 

0.9 

1.98 

1.13 

37.96 

97,67 

67.81 

60,00 

SP MULTIPLY 

1.8 

3,44 

2.52 

79,95 

112,09 

96.01 

38.42 

SP DIVIDE 

1,92 

6.72 

3.54 

91.05 

108.77 

99,91 

28.23 

DP ARITHMETIC 








DP ADD 

0.9 

4.14 

0.98 

42,45 

184,08 

113.27 

116.58 

DP SUBTRACT 

0.9 

4.14 

1.10 

43,35 

184.98 

114.17 

98.42 

DP MULTIPLY 

3.06 

6.22 

4.68 

193,05 

280,98 

237,02 

50,65 

DP DIVIDE 

3.12 

14.4 

6,0 

239.25 

259.98 

249.62 

41,60 


a ALL INSTRUCTIONS PRESENTED HERE ARE FLOATING POINT INSTRUCTIONS. SP » SINGLE-PRECISION; 
DP - DOUBLE-PRECISION. 
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to the PDP. The conclusion drawn from this study is that 
the LSI is 45 to 50 times slower tnan STL's PDP-11/70. 

3 . 2 . 1 . 2 Actual PDP-11/70 FORTRAN Operation Execution Times 

To estimate the time required to execute a piece of FORTRAN 
code, the total time required to perform the arithmetic 
operations and trigonometric functions is needed. This was 
obtained by timing each of these operations on the PDP-11/70 
(dedicated) as follows: 

1. A utility program was developed to time an individ- 
ual line of code. To make the time large enough to 
be noticeaole in seconds, a loop was added to exe- 
cute the statement 10,000 times. 

2. Tne code was timed without the statement containing 
the operation in question. This provided the over- 
head time in the loop. 

3. Each operation was put in the simple arithmetic 
statement and timed. After subtracting the over- 
head, the average test time was computed for each 
type of operation. This process was repeated for 
the trigonometric functions. 

Table 3-2 specifies the results of this study, including the 
minimum, maximum, and typical times for both single- and 
double-precision operations and functions. The typical 
times specified are used to estimate tne timing requirements 
of the AOD3 functions. 

3. 2. 1.3 Timing of Existing software 

Existing pieces of software, similar to those tnat will be 
developed for AODS, were located and timed on the 
PDP-11/70. Table 3-3 presents tne results of these timing 
tests. In each case, the target code was executed 100 to 
1000 times and averaged to obtain a reasonaole time 
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Table 3-2. PDP-11/70 Timing Test Results 


OPERATION 

TIME (mi) ' 

MINIMUM 

MAXIMUM 

TYPICAL 

SPADD 

0.00664 

0,00896 

0,008 

SP SUBTRACT 

0.00664 

0,00896 

0.008 

SP MULTIPLY 

0.00816 

0,0'r054 

0,010 

SP DIVIDE 

0.00818 

0.01366 

0.012 

SP SINE 

0,07773 

0,12149 

G.1 IQ 

SP COSINE 

0.08164 

0.13946 

0,122 

SP TANGENT 

0,179688 

0,18008 

0.180 

SPARCSIN 

0,21836 

0,23789 

0,234 

SP ARCCOS 

0.22774 

0,26664 

0,248 

SP ARCTAN 

0.13164 

0,15352 

0.143 

SP SORT 

0.06463 

0,05664 

0,056 

DP ADD 

0.0082 

0,01018 

0,009 

DP SUBTRACT 

0,00816 

0,00976 

0.009 

DP MULTIPLY 

0.01133 

0,01446 

0.013 

DP DIVIDE 

0.01133 

0,02861 

0.022 

DP SINE 

0.13166 

0,21132 

0,095 

DP COSINE 

0,13166 

0,21992 

0,200 

DP TANGENT 

0,28477 

0,28616 

0,285 

DP ARCSIN 

0.21624 

0,29336 

0,278 

DP ARCCOS 

0 22696 

0,22852 

0,228 

DP ARCTAN 

0,20362 

0,26992 

0,237 

DP SORT 

0,07695 

0,08633 

0,083 


7359/80 





i 


ordinal 


. is 

QUAUTV 


Table 3-3. Execution Times of Existing Software Components 


TIMING TEST 

COMPONENT 

EXECUTION TIME 

USER SPACECRAFT (SMMl PROPAGATION! 
SQ.OOO-SECQNQ SPAN, @0-SECQND STEPSIZE 
11000 STEPS), 2-BY.2, DRAG 

INTEL PROPAGATOR 

9,0 SECONDS 
(0.009 SECOND PER 
STEP) 

USER SPACECRAFT (SMM) PROPAGATION! 
60,000-SECOND SPAN, 60-SECOND STEPSIZE 
(1000 STEPS), 8-BY-8, DRAG 

INTEL PROPAGATOR 

IB, 7 SECONDS 
(0.016 SECOND PER 
STEP) 

USER SPACECRAFT (SMM) PROPAGATION: 
60,000-SECOND SPAN, 60-SECOND STEPSIZE 
(1000 STEPS), 8-BY-8, DRAG, SUN AND MOON 

INTEL PROPAGATOR 

28.4 SECONDS 
(0,028 SECOND PER 
STEP) 

TDRS SPACECRAFT PROPAGATION! 60,000- 
SECOND SPAN, 60-SECOND STEPSIZE (1000 
STEPS), 8-BY-B, SOLAR RADIATION, SUN 
AND MOON 

INTEL PROPAGATOR 

27.9 SECONDS 
(0,028 SECOND PER 
STEP) 

10-BY-10 MATRIX INVERSION 

SUBROUTINE IV 

0.492 SECOND 

TWO-WAY RANGE AND DOPPLER COMPUTA- 
TION WITHOUT PARTIALS 

TWO-WAY OBSER. 
VATION MODEL 

0.024 SECOND 

TWO-WAY RANGE AND DOPPLER COMPUTA- 
TION WITH PARTIALS 

two-way obser. 

VATION MODEL 

0.029 SECOND 
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estimate. These times ace used in the throughput analysis 
and in the computation of program overhead time. 

3. 2. 1.4 Estimation of Execution Time 


Using the FORTRAN operation execution times determined in 
Section 3, 2. 1,2 and the FORTRAN code for a particular func- 
tion, it should be possible to estimate the execution time 
required to perform that function. However, Table 3-2 does 
not contain times for operations such as load, store, 
branch, and compare or for integer arithmetic operations 
(index computations, counters, and so fortn) . In sample 
cases in which the actual execution time wa3 known, the exe- 
cution time was also estimated based on the FORTRAN code. 

It was found that on tne average the estimate was approxi- 
mately one-half the actual execution time. After examining 
the code, this difference was attributed to the previously 
specified operations for which actual execution times are 
not known. Tnus, when estimating execution time using this 
method, the estimate should be increased by a factor of two 
to account for noncomputational statements and integer 
ar ithmetic. 

* 

3 . 2 . 1 . 5 Input/Output Timing 

The time required to perform input or output was determined 
using the information given in Appendix C. First, the total 
size of each type of data block, including all record 
headers and filler bytes, was computed. Then the transmis- 
sion times were computed based on two different transmission 
rates: a typical flight transmission rate (2100 bits per 

second for uplinic and 56,200 bits per second for downlink) 
and the speed of the lines that will be used for data trans- 
mission in the prototype system (9600 bits per second for 
both directions) . Tables 3-4 and 3-5 present the transmis- 
sion times for input and output messages, respectively. 

These times are used in the throughput analysis. 
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Table 3-4. Input Message Transmission Times 



TOTAL 

BYTES 

UPLINK TIME (we) 

INPUT MESSAGE BLOCK 

AT 2100 BITS/ 
SEC 

AT 9600 BITS/ 
SEC 

OBSERVATIONS (BURST OP 60) 

6,120 

19,5 

4,267 

OBSERVATIONS (60 BURSTS OF 1 ) 

15,360 

68,61 

12,8 

INITIALIZATION TABLE 

256 

0,975 

0,213 

NEW TDRS VECTORS (3) 

768 

2,9 

0,04 

ESTIMATION CONTROL PARAMETERS 

256 

0,975 

0,213 

MANEUVER SCHEDULE 

1,024 

3,9 

0,863 

TRACKING SCHEDULE 

512 

1,96 

0,4267 

MISCELLANEOUS CONSTANTS 

256 

0.976 

0,213 

STATION CONSTANTS 

1,280 

4,876 

1,067 

GEOPOTENTIAL TABLES 

1,280 

4,876 

1,007 

ATMOSPHERIC DENSITY TABLES 

768 

2,9 

0,64 

TIMING COEFFICIENTS 

256 

0,975 

0,213 

COMMAND 

256 

0,975 

0,213 


Table 3-5. Output Message Transmission Times 



TOTAL 

BYTES 

DOWNLINK TIME ( 50 c) 

OUTPUT MESSAGE BLOCK 

AT 66,200 BITS / 
SEC 

AT 9,600 BITS/ 
SEC 

STATE VECTOR PREDICT TABLE (1 HOUR) 

2,816 

0,05 

0,293 

STATE VECTOR PREDICT TABLE (’/, HOUR) 

1,636 

0,027 

0.16 

PREDICTED ONE-WAY DOPPLER (100 OBSER- 
VATIONS) 

3,328 

0.0592 

0,3467 

PRIORITY MESSAGE 

256 

0.00456 

0.0267 

ACTIVITY LOG 

5,632 

0,1 

0,5867 

DC SUMMARY AND STATISTICS REPORT 

708 

0,0137 

0.08 

DC RESIDUALS REPORT 

26,112 

0,465 

2.72 
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3.2.2 COMPUTER MEMORY REQUIREMENTS 


The computer memory requirements for AODS were estimated 
based on similar existing software and the amount of data to 
be stored. The data storage requirements were computed as- 
suming that all data mu 3 t be stored internally in memory/ 
since no peripherals will be available. In addition/ the 
size of the software components was estimated witn the un- 
derstanding that overlaying will not be possible. 

Table 3-6 specifies the AODS data storage requirements. The 
sizes of the observation and TORS orbit files were estimated 
based on the data dictionary (Appendix B) and the functional 
requirements given in Section 2.3.1. The sizes of the other 
data storage were estimated according to the description of 
the data given in the data dictionary and the input and out- 
put message formats (Appendix C) . 

Table 3-7 presents the estimated sizes of the AODS software 
components. The components listed will perform the main 
functions in AODS. Since the sizes were estimated based on 
similar existing software components of other systems, tne 
names of the system in which it was found and the computer 
on whicn it is implemented are also provided. 

Based on the estimates presented here, AODS as it is defined 
in Section 2 will fit on an LSI-11/23 with 256K oytes of 
RAM. AODS will occupy approximately 200K bytes, and the 
operating system and nandlers will use 12K oyces, leaving 
about 44K bytes for the input message queue (which is not 
included here because it can be made a var: ole size) . Tne 
memory requirements specified here are only estimates and 
are subject to error. If, for example, the size estimates 
were under by 15 percent, there would probably be insuffi- 
cient space for the program and data as presented here, and 
further studies would be required. 
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Data Storage Requirements 


TYPE OF DATA 

SIZE (bytes) 

OBSERVATION FILE (BOO OBSERVATIONS) 

26,000 

TDRS ORBIT FILES (SO HOURS) 

28,944 
(9,648 PER 
FILE) 

INITIALIZATION TABLE 

188 

NEW TDRS VECTORS 

174 

ESTIMATION CONTROL PARAMETERS 

62 

MANEUVER SCHEDULE 

928 

TRACKING SCHEDULE 

288 

CONSTANTS 

3,078 

CONTROL COMMAND 

100 

STATE VECTOR PREDICT TABLE (1 HOUR'S WORTH OF VECTORS AT 30- 
SECOND INTERVALS) 

1,260 

PREDICTED ONE-WAY DOPPLER OBSERVATIONS (100 OBSERVATIONS) 

2,904 

ERROR MESSAGE 

46 

ACTIVITY LOG 

5,0L f i 

DC SUMMARY AND STATISTICS REPORT 

504 

DC RESIDUALS REPORT (600 OBSERVATIONS) 

24,000 

BATCH MATRICES 

880 

STATE SOLUTION 

88 

OBSERVATION QUEUES 

4,400 

ESTIMATION PARAMETERS 

400 

TDRS INTEGRATION START DATA (180 PER PROPAGATION) 

1,080 

TARGET INTEGRATION START DATA (180 PER PROPAGATION) 

640 

TARGET STATE TRANSITION MATRIX INTEGRATION ACCELERATIONS 

1,460 

TOTAL ESTIMATED AODS DATA STORAGE REQUIREMENT: 

101 ,324 
(102K BYTES) 
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Table 3-7. Estimated Size of AODS Software Components 


AODS COMPONENT 

SOURCE OF EXAMPLE 

MACHINE 

ESTIMATED SIZE 
(K-byto*) 

ORBIT PROPAGATOR (SUN, MOON, 
DRAG, 8-BY-8) 

INTEL PROPAGATOR 

PDP-11 /70 

12 

GEOPOTENTIAL MODEL (15-BY-15I 

GTDS 

IBM S/360-96 

4 

STATE TRANSITION MATRIX 

GTDS 

IBM S/360 -95 

4 

OBSERVATION MODELS 




TWO-WAY TDRSS 

TWO-WAY TDRSS MODEL 

PDP-11/70 

5 

ONE-WAY TDRSS 

TWO-WAY TDRSS MODEL 

PDP-11 /70 

5 

THREE-WAY TDRSS 

TWO-WAY TDRSS MODEL 

PDP-1 1/70 

5 

ONE-WAY SRE 

GTDS 

IBM S/360-95 

5 

TWO-WAY SRE 

GTDS 

IBM S/360-96 

5 

BATCH WEIGHTED LEAST-SQUARES 

ENTREE 

CDC CYBER 170 

2 

MATRIX MULTPUCATION AND 
INVERSION 

ENTREE 

CDC CYBER 170 

2 

OBSERVATION ACCEPTANCE AND 
REDUCTION 

GTDS 

IBM S/360-95 

2 

ESTIMATION EXECUTIVE 

ENTREE 

CDC CYBER 170 

6 

INPUT PROCESSING 



8 

OUTPUT PREPARATION AND 
TRANSMISSION 

! 


4 

DATA MANAGEMENT 



4 

OVERALL EXECUTIVE (CONTROL) 



16 


TOTAL ESTIMATED AODS SOFTWARE SIZE: 

89 i 10% 

(UPPER LIMIT: 981 







3.3 THROUGHPUT ANALYSIS 


The object of throughput analysis is *-o show the feasibility 
of executing the proposed software on. u. •> specified hardware 
system in the required amount of time. Tnis is done by 
identifying a worst case path through the system, estimating 
or locating the actual execution time for each of the major 
functions in that path, and computing the execution time of 
that path. Usually, two throughput analyses are performed. 
First, a worst case throughput analysis is performed to show 
the feasibility of implementing the software system on the 
specified hardware. Second, a typical case throughput anal- 
ysis is performed to determine the typical amount of execu- 
tion time that will be required to perform the intended 
functions and, conversely, the amount of idle time that will 
be available for other processing. 

Due to the real-time processing requirement, AODS must be 
able to complete orbit determination on each batch of obser- 
vation data before the next pass of raw tracking data is 
received. A pass of tracking data is to be uplinked once 
per user spacecraft revolution. In addition, AODS must per- 
form all its regularly scheduled functions (e.g., one-way 
Doppler prediction and output, state vector predict table 
generation and output, activity log output, data capture) 
during the same processing period. 

For the throughput analyses presented in this section, the 
maximum possible processing time is 90 minutes (5400 sec- 
onds) , which is considered to be the minimum revolution time 
of a user spacecraft. Sections 3.3.1 and 3.3.2 present the 
throughput analyses of the .worst case and the typical case, 
respectively. Each case covers the timespan from the time 
that a pass of observations is received until the next pass 
of data is received (1-1/2 hours later) . The cases are 
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broken down into the major functions performed, and an esti- 
mated execution time is assigned to each one. The execution 
times were estimated in the following manner: 

• All propagation times were estimated using the max- 
imum execution time per step (0,028 second) speci- 
fied in Table -3-3. It was assumed that the 
inclusion of the Sun and Moon forces in the propa- 
gation of the user spacecraft more than compensated 
for the lack of an actual time for the state tran- 
sition matrix propagation (variational equations) . 
(The largest geopotential table used was 8-by-8. 

If a 15-by-15 table were to be used, the time per 
step would increase significantly.) 

® The matrix inversion and observation modeling times 
were taken from Table 3-3. 

• The data capture and output times were taken from 
Taoles 3-4 and 3-5, respectively. The data rate of 
9800 bits per second, which will be used by the 
prototype AODS, was used. 

« The data retrieval times were estimated based on a 
task interface time of 0.2 millisecond (see Refer- 
ence 6) . 

• All other times were estimated using the operation 
times specified in Table 3-2 and the computational 
model for the function. These times have been ad- 
justed by the overhead factor determined in Sec- 
tion 3. 2. 1.4. 

The execution times in the tnroughput analyses are ir. units 
of seconds unless otherwise specified. Times marked with an 
asterisk (*) are input/output times. 
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3.3.1 WORST CASE THROUGHPUT ANALYSIS 

The functions included in the worst case for 
batch of data in AODS are as follows: 


AODS Function 


1. Capture one pass of raw tracking data 

(100 observation pairs) 

2. Preprocess 100 observation pairs 

3. Pregenerate three TDRS orbit files over 

the next revolution (90-minute span, 

10-minute stepsize) 

4. Generate two 30-minute state vector 

tables (60-second stepsize) 

5. Output two 30-minute state vector tables 

6. Initialize estimation (move epoch) 

7. Perform one batch iteration 

a. Retrieve 500 observation pairs 

b. Retrieve TDRS vectors for inter- 
polation (groups of eight) 

c. Propagate user spacecraft state 
vector and state transition 
matrix over 12 hours (60-second 
stepsize) 

d. Compute 500 observation pairs with 
par tials 

e. Propagate observation partials to 
epoch (1000 observations) 

f. Accumulate batch statistics 
(1000 observations) 

g. Invert normal matrix (10-by-10) 

h. Solve for state update (10 param- 
eters) 

i. Update state vector 

j. Generate DC Summary and Statistics 
Report 


processing one 

PDP-11/70 
Execution 
Time (Seconds) 

7.112* 

0.015 

0.756 

1.68 

0.32* 

2-52 

0.1 

0.0052 

20.16 

14. 5 

3.74 

6.58 

0.49 
0.00 4 

0.0002 

0.002 
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AODS Function 


PDP-11/70 
Execution 
Time (Seconds) 


k. 


Output DC Summary and Statistics 0.080 

Report 

(Total for 7: 45.6614) 


8. Generate DC Residual Report 

9. Output DC Residual Report 

10. Assuming convergence occurred, gen- 
erate new 60-minute state vector 
predict table based on new solution 

11. Output 60-minute state vector table 

12. Capture and store input data 

a. Capture the following data sets: 

(1) Maneuver schedule 

(2) Tracking schedule 

(3) Estimation control parameters 

(4) Initialization table 

(5) Station parameters 

(6) Geopotential tables 
(7> Drag tables 

(8) Timing coefficients 


0.12 

2.72* 

1.68 


0.293* 


0.853* 
0.427* 
0.213* 
0 . 210 * 
1.067* 
1.067* 
0. 640* 
0.213* 


b. Store these data sets 

(Total for 12: 

13. Capture three new TORS vectors 

14. Update three TDRS oroit files with 
new vectors (12-hour span, 10-minute 
stepsize) 

15. Predict one-way Doppler observations 
(two 15-minute tracking intervals, 
one observation per 10 seconds) 

16. Output one-way Doppler observations 
(two intervals) 

17. Output three activity logs 

18. Output priority message 


2. 84 
7.53) 
0. 64* 
6.048 


5. 16 

0. 624* 

1. 76* 
0.027* 


To demonstrate the feasibility and/or limitations of imple- 
menting AODS on the LSI-11/23, the number of batch itera- 
tions possible in the 90-minute maximum time span are 
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computed. First the input/output and central processing 
unit (CPU) times for functions that are not part of the 


batch iteration are 

summed : 


Function 

CPU Time 
(Seconds) 

Input/Output 
Time (Seconds) 

1 


7.112 

2 

0.015 


3 

0.756 


4 

1.68 


5 


0.32 

6 

2.52 


8 

0.12 


9 


2.72 

10 

1. 68 


11 


0.293 

12 

2.84 

4.69 

13 


0.64 

14 

• 6.048 


15 

5.16 


16 


0.624 

17 

* 

1.76 

18 


0.0 27 


20.819 

18.186 


Using tne worst case execution time for one batcn iteration, 
the number of iterations possible can be computed as follows 

5400 = 20.819 + 18.186 + 45.6Sx 
5400 = 39 + 4 5 . 66x 
5361 = 45.66x 
x * 117.4 

Thus, 117.4 iterations could be performed on the PDP-11/70. 
Converting the CPU times to L3I-11/23 times, the total 
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number of iterations possible on tne LSI-11/23 can be com- 
puted as follows: 


5400 = 995.1482 + 18.186 + 2182.548x 

5400 = 1013.33 + 2182. 548x 

4386.67 = 2182.548k 

k = 2.01 

Thus, only 2.01 batch iterations could be performed on the 
LSI-11/23 in the worst case. 

3.3.2 TYPICAL CASE THROUGHPUT ANALYSIS 

The functions included in the typical case for processing 
one batch of data in AODS are as follows: 


AODS Function 


PDP-11/70 
Execution 
Time (Seconds) 


1. 

Capture one pass of raw tracking data 
(60 observation pairs) 

4. 267* 

2. 

Preprocess 60 observation pairs 

0.013 

3. 

Pregenerate three TDRS orbit files over 
the next revolution (90-minute span, 
10-minute stepsize) 

0.756 

4. 

Generate the 30-minute state vector 
tables (60-second stepsize) 

1.68 

5. 

Output two 30-minute state vector tables 

0.3 2* 

6. 

Initialize estimation (move epoch) 

2.52 

7. 

Perform one batch iteration 
a. Retrieve 480 observations 

0.096 


D. 

Retrieve TDRS vectors for inter- 
polation (groups of eight) 

0.0052 

C. 

Propagate user spacecraft state 
vector and state transition matrix 
over 12 hours (60-second stepsize) 

20.16 

d ♦ 

Computer 480 observation pairs 
with partials 

13.92 

e. 

Propagate observation partials to 
epoch (960 observations) 

3.59 
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PDP-11/70 

Execution 




AODS Function 

Time (Seconds) 


f. 

Accumulate batch statistics 
(960 observations) 

6.32 


g* 

Invert normal matrix (10-by-10) 

0.49 


h. 

Solve for state update (10 param- 
eters) 

0.004 


i. 

Update state vector (10 parameters) 

0.0002 


j- 

Generate DC Summary and Statistics 
Report 

0.002 


k. 

Output DC Summary and Statistics 
Report 

0.08 



(Total 

for 7: 44.6674) 

8. 

Generate DC Residual Report 

0.12 

9. 

Output DC Residual Report 

2.72* 

10. 

Assuming convergence occurred, gen- 
erate new 60-minute state vector 

1.68 


predict table based on new solution 

11. Output 60-minute state vector table 0.29'3* 

12. Predict one-way Doppler observations 1.72 

(one 10-minute tracking interval, one 
observation per 10 seconds) 

13. Output one-way Dopp..er observations 0.208* 

(one interval) 

14. Output three activity logs 1.76* 

15. Output priority message 0.027* 

All functions in the typical case that are not part of the 

batch iteration are summed as follows: 


Function 

CPU Time 
(Seconds) 

Input/Output 
Time (Seconds) 

1 


4.267 

2 

0.013 


3 

0.756 


4 

1. 68 


5 


0.32 

6 

2.52 
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Function 

CPU Time 
(Seconds) 

Input/Output 
Time (Seconds) 

8 

0.12 


9 


2.72 

10 

1.68 


11 


0.293 

12 

1.72 

1.72 

13 


0.208 

14 


1.76 

15 


0.027 


8.489 

9.595 


Using the typical execution time foe one batch iteration, 
the number of iterations possible on tne PDP-11/70 can be 
computed as follows: 

5400 ■ 8,483 + 3,595 + 44. 66x 
5400 = 18.084 + 44.66x 
5381.9 = 44 . 66x 
x = 120 . 5 

Converting the CPU times into LSI-11/23 times, the uypical 
number of iterations possible on the LSI-11/23 can be com- 
puted as follows: 

5400 = 405.77 + 9.595 + 2134. 748x 
5400 = 415.37 + 2134. 748x 
4984.63 = 2134. 7484x 
x = 2.335 

Thus, in the typical case, only 2.335 catch iterations can 
be performed. 

3.3.3 CONCLUSIONS AND RECOMMENDATIONS 

The key to the timing problem is the orbit propagator. A 
careful study of the throughput analyses shows tnat 45 per- 
cent of each batch iteration is spent propagating the user 
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spacecraft state. In addition, approximately 60 to 80 per- 
cent (64 percent in the worst case and 79 percent in the 
typical case) of the CPU time of tne other (noniterative) 
activities is spent in the orbit propagator. It is to be 
remembered that an 8-by-8 geopotential model and a fourth- 
order Runge-Kutta integrator were used in the the throughput 
analyses. If a larger model such as a 15-by-15 model were 
used, the time spent in the propagator would be longer. 
Therefore, great care should be taken in selecting the force 
models that will be implemented in AODS. That is, no more 
than those aosolutely necessary should oe included. 

An alternative to the reduction of the orbit propagator to a 
"bare-bones" force model is the addition of a second micro- 
processor that would perform all orbit propagation, thereby 
removing it from the main processor. Tnis would allow the 
main processor to request an orbit propagation and then pro- 
ceed witn its otner functions while the second processor 
performs the propagation. Using the execution times speci- 
fied in Section 3.3.2, the effectiveness of this configura- 
tion can be demonstrated. By reducing the execution times 
of the noniterative functions and the catch iteration by 64 
and 45 percent, respectively, the following equation is ob- 
tained : 

5400 = 265.84 + 1174. llx 
5134.16 = 1174. llx 
x = 4.373 

Thus, the productivity of AODS has in effect been doubled. 

Another alternative is to change the method of estimation to 
a noniterative method such as a standard or extended Kalman 
filter. Since the time required to perform the estimation 
by filtering would be approximately the same as that re- 
quired to perform one batch iteration, even the worst case 
would have a substantial amount of "free time." However, 
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the question of estimation reliability must dictate the fea- 
sibility of this suggestion, 

3 , 4 ERROR CONTINGENCY PLAN 


Thi3 section, which presents a philosophy for error handling 
in AODS, is intended to advise the designer in handling 
those errors which will be identified during AODS design. 
AODS errors fall into four general categories: computa- 

tional errors, algoritnmic errors, input data errors, and 
operational errors. All errors will be recorded on the ac- 
tivities log, and severe error messages will be downlinxed 
immediately. The following subsections give the philosophy 
for handling each of the error types and some examples of 
each. 

3.4.1 1 COMPUTATIONAL ERRORS 

Computational errors are arithmetic errors that are detected 
by the machine (e.g., overflow, underflow, divide checK) . 
These errors should be avoided by implementing safeguards in 
the AODS code as well as removing outlying data points that 
would randomly cause such errors. 

3.4.2 ALGORITHMIC ERRORS 

Algorithmic errors, which will be detected by AODS itself, 
are those errors that occur as part of, or as a result of, a 
particular algorithm or computational model (e.g., estimator 
divergence, normal matrix singularity, editing of too much 
data by the estimator) . These errors will be handled ac- 
cording to the specifications that will be given by the as- 
sociated GSFC analysts. However, until that time, a 
temporary procedure for handling these errors has been de- 
fined. In cases of algorithmic errors in estimation, the 
estimator will be terminated, and the state vector will not 
be updated. 
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3.4.3 INPUT DATA ERRORS 


There are two types of input data errors: transmission er- 

rors and numerical errors. In the case of transmission er- 
rors (e.g., incomplete block, missing records, unidentified 
data type) , the data block should be discarded and a re- 
transmission request downlinked immediately. 1 In the case 
of numerical errors (e.g., unreasonable values for observa- 
tion measurements and time tags) , the data should be dis- 
carded and the errors recorded on the activity log. 

3.4.4 OPERATIONAL ERRORS 

Operational errors are those errors which could occur a3 a 
result of the operation of the program and/or would have a 
significant effect on program operation. Because of tne 
wide variety of errors in this category, each error requires 
special error handling. Three AODS errors of this type are 
foreseen at this time. These operational errors and their 
solutions are as follows: 

ERROR: AODS falls behind schedule in processing. 

SOLUTION: Since estimation will be the lowest priority 

function, it will absorb the effects of this 
problem. The estimator will continue until it 
has completed estimation on its current batch of 
data. When it has completed estimation, the next 
pass of data will be added to the ooservation 
file. However, no estimation will occur on this 
batch of data. When the next pass of data is 
received, it will be added to tne observation 
file. The estimator will then slide forward (two 
passes of data) , and normal processing will 
resure. By eliminating one estimation process, 


It is assumed that the normal system hardware will perform 
this function. 


*1 

4 
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ERROR: 


SOLUTION : 


ERROR: 


* 


much time will be saved without seriously impact- 
ing tne regular operation o£ AODS. 

The maneuver or tracking schedule is received 
late (i.e., received after tne scneduled start 
time) . 

AODS should assume that all times earlier than 
the "current time" are in error. AODS will re- 
cord the errors and resume normal operations with 
the first entry that is greater than or equal to* 
the current time. 

Constants (station constants, geopotential 
tables, drag tables, timing coefficients) are 
received during estimation. 

AODS will ignore (discard) these data and re- 
cord the error in tne activity log. 


SOLUTION: 


SECTION 4 - AODS DEVELOPMENT STRATEGY 


This section, intended as a guide for the AODS designer, 
presents a philosophy of implementation, or development 
strategy, for AODS. 

To achieve a prototype AODS by the spring of 1981, it will 
be necessary to implement the system in steps, each step 
demonstrating a major feature of the final system. Fig- 
ure 4-1 shows this proposed systematic development from the 
early microprocessor activities (i.e., development of the 
IMP-16 microprocessor Onboard Determination System (ODS) 
demonstration system; see Reference 8) to the final flight- 
qualified system. This implementation plan is based on the 
time schedule specified by GSFC and has not been modified 
based on this document. The major milestones of the pro- 
posed schedule are as follows: 

® Current activities 

Design the prototype AODS from the results of 
the requirements analysis. 

1 Implement portions of the system such that the 
primary input and output capabilities can be 
fully exercised and checked in a simulation 
environment. 

Design and implement the environment simula- 
tor, ADEPT. 

• Future activities 

Add to the prototype AODS the mathematical 
algorithms specified in (1) the previous de- 
sign activity and (2) analysis performed out- 
side the microprocessor Software Support t&- 

Move the system to, and test it on, the 
LSI-11/23 microcomputer. 
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Figure 4-1. GSFC-Specified Schedule for AODS Development 





This section dis.cusses the implementation of the system ac- 
cording to the proposed time schedule. Section 4.1 dis- 
cusses the implementation of the prototye AODS executive and 
simulator (first build) and the assembly of the prototype 
system on the PDP-11/70 minicomputer. Section 4.2 discusses 
the implementation of the mathematical algorithms into the 
prototype system; the moving of the system to, and its test- 
ing on, the LSI-11/23 microcomputer (second build) ; and the 
development and implementation of a final flight-qualified 
system. Throughout tne development of both AODS and ADEPT, 
modern software practices will be adhered to; specifically, 
these include use of the following: 

• Top-down design 

• Design reviews 

• Code walk-throughs 

• Librarian 

• Chief programmer 

4. 1 CURRENT ACTIVITIES (BUILD 1) 

The current statement of work (Task 989, Amendment 2) de- 
scrioes tne goals to be achieved during the current tasking 
period (spring 1980 through fall 1980). The statement di- 
rects that the AODS executive (driver) will be implemented 
and tested on the STL PDP-11/70 minicomputer. The degree of 
implementation will be such that primary input and output 
capabilities can be fully exercised and checked in a simula- 
tion environment. In addition, the control logic for invok- 
ing various subsystems and the corresponding stubs will be 
implemented. The environment simulator, ADEPT, will also oe 
fully implemented and tested. Section. 4.1.1 and 4.1.2 dis- 
cuss tne AODS and ADEPT implementation strategies, respec- 
tively, and the assembly of the prototype system on the 
PDP-11/70. 
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4.1.1 AODS IMPLEMENTATION (FIRST BUILD) 


Although AODS will be completely designed under the current 
tasking period (spring 1980 through fall 1980) , only se- 
lected system processes will be implemented. The processes 
to be implemented include 

• Data capture 

• Input message processing 

• Executive control 

• Output message preparation 

• Output message transmission 

The remaining processes will be implemented as stubs with 
their proper interfaces. The following processes will not 
be implemented: 

• Data preprocessing 

• State estimation 

• Data’ base management (observations and TDRS vectors) 

• One-way Doppler observation prediction 

• State vector predict table generation 

Implementation will begin when the design of the processes 
to oe implemented has been completed. During this first- 
build implementation stage, the design of the remaining 
processes (i.e., those not to be implemented at this stage) 
will be completed. 

4. 1.1.1 Data Capture 

AODS will capture all messages uplinked to AODS from ADEPT 
and put these messages in an input queue for use by the in- 
put message processor. In the first build, both AODS and 
ADEPT will reside in the same PDP-11/70 computer, and com- 
munications over an external line will not be necessary to 
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pass data between programs. 1 Instead, a scheme such as 
that shown in Figure 4-2 will be used. Figure 4-2 shows two 
tasks (uplink and downlink) that act as the communications 
interface between ADEPT and AODS. Each task, when given 
control, loads data in the appropriate queues in the same 
manner as will the final communications software. The two 
tasks will have a high priority in the system and should be 
serviced immediately. An additional function of the uplink 
task will be to recognize commands and, in many cases, ini- 
tiate the action to carry out the commands. The uplink 
tasks will also notify the AODS executive if the input queue 
is nearly full. This scheme should protect AODS and ADEPT 
from major modifications when, in future builds, AODS is 
moved to the LSI-11/23, and external communicatons (i.e., 

QIO and WTQIO system directives using an asynchronous trap 
(AST)) are required. The first-build data capture routine 
will not allow loading of partitions of code or perform any* 
validity checking (such as parity or cyclic redundancy) . 

4. 1.1. 2 Input Message Processing 

The first-build AODS will perform all functions specified in 
the AODS input requirements, including decoding and identi- 
fying all input messages, storing the identified data in the 
proper data sets, and extracting the usable portions of tne 
raw observation message and storing the reduced observation 
in the proper queue based on observation type. Specifi- 
cally, the first-build input message processor will accept 


Hfork has oeen done to simulate communications between the 
PDP-11/70 and the LSI-11/23 by installing wraparound ca- 
bling between input/output ports on the PDP-11/70. The cur- 
rent work is preliminary, and techniques to communicate over 
the lines have not been finalized. 
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data from the data capture input message queue and more data 
into the proper COMMON block. The data to be moved include 

9 Raw observation messages 

• New TDRS vectors 

9 Maneuver schedule 

• Initialization tables 

9 Tracking schedule 

• Miscellaneous constants 

• Estimation control parameters 

• Station parameters 

• Geopotential tables 

• Atmospheric drag tables 

• Timing coefficients 

The receipt of all input messages will be recorded in a 
COMMON block used by the executive to form the activities 
log. The input message processor will be called from the 
executive only when there is an indication of data in the 
input queue. If there is an unusual condition in the input 
message processor (e.g. f full reduced observation queue, 
missing records, incomplete records, mixing of different 
types of data in a block, 'error in data size in a record, 
invalid type of data) , the task will report this condition 
to the executive. 

4. 1.1. 3 Executive Control 

Executive control is the key part of AODS implementation. 
Design decisions made relative to the AODS executive will 
affect all tasks in the system, thus much attention will be 
given to this important software module and in the first- 
build AODS. 

The AODS executive will determine scheduling needs (next 
action(s)) through a decision tree or table; maintain a 
table of active tasks and their levels of priority; communi- 
cate with the RSX-11M operating system coordinating the 
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tasks to be scheduled and their levels of priority; specify 
the amount of time (i.e., time slice) the scheduled tasks 
are allowed for completion before control returns to the 
executive; and maintain and output the activities log. 

Figure 4-3 shows the basic scheduling mechanism of the exec- 
utive, which is as follows: 

1. Through input (e.g., tracking schedule, maneuver 
Schedule, status of task currently scheduled, com- 
mand messages, system clock time) , the executive 
determines the content of the scheduling table. 

2. _ The executive reads the scheduling table, resuming 

tasks in the requested order (execution priority) . 

3. Using a mark time system directive and an AST, the 
executive sets up a time at which to be reactivated. 

An AODS executive design goal will be to design as much of 
the software as possible in FORTRAN, but in some cases as- 
sembly language must be used (e.g., for issuing the mark 
time with the AST, for the AST routines themselves) . The 
RSX-11M system services expected to be used by the AODS 
executive are as follows: 

• 3USPEND/RESUME--initiates tasks to be executed 

• ALTER PRIORITY--controls order of execution 

• MARK TIME WITH AST--allows time slicing of tasks 

• ABORT--allows removal of unwanted tasks from con- 
sideration 

• CANCEL MARK TIME 

4. 1.1. 4 Output Message Preparation 

Six types of messages will be output from AODS: 

• Residual Report 

• DC Summary and Statistics Report 

• Activities log 
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AODS EXECUTIVE CONTROL 


ORIGINAL PAGE IS 
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Figure 4-3. Executive Control 




• Error messages 

• One-way predicted Doppler observations 

• Target state vectors 

In the first-build AODS, the mechanisms for generating these 
messages will be implemented, but the messages themselves 
will be fixed in a global area. This implies that the stub 
tasks that perform output (e.g., state estimation task) will 
contain the proper communication and logic to inform the 
AODS executive to resume the output task. Figure 4-4 shows 
the output preparation procedure. To perform output, a tasx 
will mark the request in an output table and mark the mes- 
sage type locked. Upon examining the output table, the AODS 
executive will resume the output preparation task. The out- 
put preparation task will then 

• Examine the output table for entries 

• Move the data to the output message buffer; during 
the move, format the data for output 

• When the move is complete, unlock the message 

• Write the message using system routine QIO (see 
Section 4. 1.1. 5) 

• Return to the first stop, looking for entries; if 
none exist, call EXITX- 1 - 

While the m .ssage type is locked, no data can overwrite it; 
therefore, tasks that must write into this buffer cannot 
progress until the unlock flag .rs set. The following tasks 
will require output service: 

• State estimation task (Residual Report, DC Summary 
and Statistics Report) 


^EXITX will be a special routine through which the subordi- 
nate tasks will exit and inform the executive of the exit 
condition. 
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INDIVIDUAL 

TASK 


MARKS ENTRIES 
IN OUTPUT TABLE; 
SETS LOCK FLAG/ 


EXAMINES LOCK FLAG 


OUTPUT TABLE 


OUTPUT 

TYPE 


LENGTH LOCK FLAG OUTPUT FLAG 


RESIDUAL REPORT 

DC SUMMARY AND STATISTICS REPORT 
ACTIVITIES LOG 
ERROR MESSAGES 

PREDICTED ONE-WAY DOPPLER OBSERVATIONS 
STATE VECTOR PREDICT TABLE 



EXECUTIVE 

CONTROL 


OUTPUT 

PREPARATION 


UNLOCKS LOCK FLAG 
AFTER DATA MOVED TO 
MESSAGE BUFFER 


EXAMINES OUTPUT 
FLAG; IF SET, 
PRESUMES OUTPUT; 


MESSAGE 

BUFFER 


SENDS 

OUTPUT 

MESSAGE 


Figure 4-4, Output Preparation 
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• State vector prediction task (state vector predict 
table) 

• One-way Doppler prediction task (predicted one-way 
Doppler observations) 

• AODS executive control task (activities log, error 
. messages) 

The global COMMON area associated with the output prepara- 
tion task is anticipated to be approximately 36,000 bytes, 
leaving 28,000, bytes for the output preparation code and 
internal buffer areas. 

4 . 1 . 1 . 5 Output Message Transmission 

The output message transmission component takes 256-byte 
messages from the message buffer (see Section 4. 1.1. 4) and 
performs the output operation. As with input data capture, 
this will be done in the first build as a SEND to the ADEPT 
downlink task. In future builds normal QIO system routines 
with ASTs will be used to perform this output function. 

Upon emptying the message buffer, the SEND routine loops 
back to prepare more output for processing. The output mes 
sage preparation and transmission components will be imple- 
mented as one task image. 

4.1.2 ADEPT IMPLEMENT/* ’ION (FIRST BUILD) 

The • environment simulator, ADEPT 1 , will support the testing 
and evaluation of AODS. The first-build ADEPT will fully 
perform this function. In addition, interfaces for growth 
features such as data error simulation (e.g., noising data, 
message corruption, transmission failure) and truth model 
comparison will be established for future builds. 
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During this tasking period, the following work will be com- 
pleted toward the eventual full implementation of tne de- 
scribed first build: 

• The detailed design of all components will be com- 
pleted. 

• The File Merge program will oe implemented. 

i 

• The data preparation task (ADPREP) will be imple- 
mented as described in this section. 

§ A skeleton executive for the ground facility simu- 
lation task (ADSIM) will be implemented. 

This level of implementation will be adequate to demonstrate 
the user interface required to set up a simulation and to 
exercise the major functions of the first-build AODS (pri- 
marily uplink and downlink communication) , 

ADEPT will support three major functions: data preparation, 

ground facility simulation, and output report generation, and 
analysis. Figure 4-5 provides an overview of the proposed 
ADEPT data flow. A orief description of each ADEPT compo- 
nent is provided oelow: 

• The File Merge program will merge tracking data 
tapes to prepare raw data files (disks) for simula- 
tion. 

• The data preparation task (ADPREP) will perform the 
following functions: 

Provide for the preparation of tne following 
data sets: initialization table, TORS vec- 

tors, estimation control parameters, maneuver 
schedules, tracking schedules, miscellaneous 
constants, station parameters, geopotential 
tables, atmospheric density tables, and timing 
coef f icients--Ench file will contain multiple 
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Figure 4-5. £OEPT Overview 














data blocks. Modification will be via inter- 
active editing of displays showing default 
values. Any existing data block may be se- 
lected as the default. Data will be stored on 
disk in binary format. 

Provide for the initial creation of the simu- 
lation schedule from the observation selection 
parameters (e.g., interval between data 
passes, length of data passes, type(s) of data 
desired, data uplink frequency, burst size)-- 
In addition, the user will assign an uplink 
time to each data block which is to be up- 
linked during simulation. The constructed 
schedule will be stored on disk in card image 
format. This may be changed during the edit- 
ing step (see below) . 

Provide verification of the simulation sched- 
ule--The simulation schedule will be printed 
with all selected data blocks. Selected 
blocks tnat are unavailable will be noted. 

Raw data will be checked for availability at 
each specified pass. 

Provide for the modification of existing or 
newly created simulation scnedules via a text 
editor . 

The ground facility simulation task (ADSIM) will 

perform the following functions: 

Prepare and uplink data to AODS as specified 
by the simulation schedule--Data blocks will 
be selected by block number and type and up- 
linked at the specified times. Raw tracking 
data will be selected by type and time tag to 


1 


build each desired pass. Data error simula- 
tion (e.g., data noise, data bias, message 
corruption, transmission failure) will not be 
available in this build, but an appropriate 
"slot" will be provided for it in the logic. 

Report AODS and ADSIM status to the operator-- 
Several levels of status reporting will be 
available, ranging from display of all activ- 
ity log and ADSIM debug messages to the dis- 
play of only critical error messages. This 
output may optionally be diverted to the 
printer . 

Accept operator commands and uplinks to AODS-- 
AODS commands may also be included in the 
simulation schedule. 

Accept and act on "immediate" operator com- 
mands to the s imulator--These are primarily 
immediate simulation schedule overrides. 
Downstream modification of the simulation 
schedule will oe performed via concurrent 
operation ol ADPREP. (Commands to ADSIM en- 
tered in this interactive fashion will not be 
written to the simulation schedule, but the 
action taken will be noted on the Simulation 
History file.) Other types of ADSIM commands 
include changes in reporting level, output to 
printer/terminal, and fast time on/off. Spe- 
cifically, the following subset of the input 
data prepared by ADPREP will be interactively 
accessible to the user- at the start of the 
simulator execution: s tar t/stop/other com- 

mands, estimation control, output control, 
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message cor rution/transmission failure proba- 
bilities, fast time options, and raw tracking 
data noise and bias. 

Receive and store output reports and predicted 
data downlinked by AODS--The DC Summary and 
Statistics Report will also be displayed/ 
printed as received under the higher status 
reporting levels. 

Write the Simulation History File--This is a 
complete real-time log of the simulation, in- 
cluding all data uplinked and received. (It 
may be on tape.) 

In build 1, provide an experimental fast time 
capability to test the feasibility of packing 
idle time out of schedules via a handshaking 
procedure with AODS 

• The output report generation and analysis task 
(ADOUT) will perform the following functions: 

Provide for the printing of operator-selected 
reports and' predicted data--Selection of the 
desired report will be by type and time tag 
(available from higher levels of status re- 
porting or the Simulation History file) . 

Provide a printout of the Simulation History 
file, which will be selected by time interval 

As previously noted, certain interfaces will be designed 
into the system but not implemented into the first build. 
These include 

• ADSIM 

Data noise/bias 
Code uplink to AODu 

Data corruption/transmission failure 
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ADOUT 


Comparison of predicted data with externally 
generated truth model, including graphics 

Full simultation history analysis, possibly 
including the ability to recreate runs 

ADEPT will be built as follows: 

• The File Merge program, ADPREP, ADSIM, and ADOUT 
will be built as separate tasks, with communication 
to the rest of the system achieved through shared 
data files. 

• ADSIM will be built around already established AODS 
data capture programs (see Section 4. 1.1.1). 

4.2 FUTURE BUILDS 

As noted earlier, the first-build AODS could evolve into a 
flight-qualified system. The steps for this evolution are 
expected to be as follows: 

1. Add computational tasks (data preprocessing, state 
estimation, data base management, and one-way Doppler pre- 
diction) based on data obtained during the design activity 
and analysis performed outside of the Microprocessor Soft- 
ware Support task--These tasks should be able to be treated 
as strict applications programs 1 since the executive con- 
trol performs most of the RSX-11M specific system services. 

2. Move AODS to, and test it on, the LSI-11/23 micro- 
computer--The code developed and tested on the PDP-11/70 
will be downloaded to the LSI-11/23. The code will be down- 
loaded using the same asynchronous serial line over which 
AODS AND ADEPT communicate. First, the operating system 

■^This means that the code developed can be 100 percent 
FORTRAN and unit tested outside the system. The algorithms 
themselves may be specially tailored to microcomputer limi- 
tations. 
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will be sent using a bootstrap program specially designed 
Eor the LSI-11/23. Next, the modified RSX-11S online task 
loader system routing will be used to load the individual 
AODS task images and data. Only two modifications to the 
AODS downloaded code are expected: (1) modification to data 

capture and send output routines to provide proper communi- 
cation and (2) establishment of specific memory maps and 
resolution in some cases of specific locations. 

3. Flight qualify the system--The final flight- 
qualified system will be much more automated than the 
LSI-xl/23 test system. It will allow for moving the operat- 
ing system and the AODS task images into a nonviolable 
memory. Upon startup of the LSI-11/23, the images will be 
bootstraped into the microcomputer. The flight-qualified 
system will also have code modified based on the actual re- 
quirements of the mission. Changes are expected to be made 
to formats of input/output messages, communication proto- 
cols, and specific uplink commands. 
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APPENDIX A - STRUCTURED ANALYSIS 


The following definitions are applicable to the data flow 
diagrams of the structured analysis techniques provided in 
Section 2: 


• Data flow is a pipeline through which packets of 
known composition flow. 

• A process is a transformation of incoming data 
flow(s) into outgoing data flow(s) . 

• A data store is a time-delayed repository of 
information. 

• A source or a sink is a system, person, or organi- 
zation lying outside the context of study that is a 
net originator or receiver of data flows tnat are 
part of the study. 

Tne ground rules for tne data flow diagrams are as follows: 

• Every data flow and data store must be named. 

• Every process must be named witn an active pnrase 
descrioing tne data transformation. 

• Data flows exiting from a process must be derivable 
from data flows entering tne process. 

• Details of each process shall be described by 
another data flow diagram. 

• Input and output shall be balanced between higher 
and lower level diagrams. 

Figure A-l is a top-level description of a system that has 
three processes (PI, P2, and P3) , four sinks and/or sources 
(SI, S2, S3 and S4) , one data store (G) , and six data ele- 
ments (A, B, C, D, E, and F) . 

Figure A-2 is the lower level description of process PI. 

The figure shows tnat at tne next level process PI may oe 
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decomposed into subprocesses Pl.l, Pi. 2, Pi. 3, and Pi. 4. 
Data elements A, B f and C must be shown at this level since 
tney are tne input and output of PI. Data elements X, Y 
and Z are data flows between the suoprocesses. The proc- 
esses at eacn level of the system can be completely de- 
scribed by a lower level diagram until the level of detail 
required for complete specification is reached. 
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ORIGINAL PAGE S3 
OF POOR QUALITY 


APPENDIX B - DATA DICTIONARY 


The data dictionary is necessary to make the data flow dia- 
grams rigorous by defining specifically tne content of each 
data element. To eliminate any ambiguity, the structured 
analysis technique utilizes a specification language called 
Structured English. This language has a limited vocabulary 
and syntax. For this study, however, conversational English 
has been used for ease of understanding by the reader. 

Tne data dictionary provided on tne following pages is or- 
ganized according to major functions. Tne data elements are 
contained in the zero-, first-, and second-level diagrams. 


B . 1 DATA DICTIONARY 
ACTIVITY LOG 

CONTROL COMMAND 


DIRECTIVES 


ERROR MESSAGE 


EXECUTION REQUEST 


GROUND CONTROL 
REQUEST 


MANEUVER SCHEDULE 


PRIORITY MESSAGE 


PREDICTED TDRS 
VECTOR AFTER 
MANEUVER 


PREDICTED USER 
SPACECRAFT VECTOR 
AFTER MANEUVER 


ORIGINAL PAGE IS 
OF POOR QUALITY 


FOR PROCESS Is CONTROL SYSTEM 


= Step-by-step account of all 
actions taken by AODS 

= Special command from ground 

control that requires immediate 
action by control (commands are 
listed under Process 2 (Sec- 
tion B. 2) ) 

= Internally generated commands 

that direct tne other processes 
(see Table B-l) 

= PRIORITY MESSAGE stating that a 

severe error from which the 
system cannot recover has oc- 
curred 

o Next action to be taken based 

on execution status 


Next action to be taken as a 
result of a CONTROL COMMAND 

Schedule of maneuvers of tne 
active TDRSs and user space- 
craft (see Process 2 (Sec- 
tion B. 2) ) 

Message tnat must oe sent im- 
mediately to ground control 
(e.g., error, idle time) 


TDRS vector after the current 
maneuver (taken from tne 
MANEUVER SCHEDULE) 


User spacecraft state vector 
after the current maneuver 
(taken from the MANEUVER 
SCHEDULE) 



fi 
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1 Table B-l. Directives 

j 


* 


i 

DIRECTIVE 

NUMBER 

DESTINATION 

PROCESS 

DIRECTIVE 

H 

1 

2 

ACCEPT START COMMAND ONLY 

9 

2 

2 

ACCEPT ALL COMPLETE INPUT MESSAGES 

* 

3 

3 

BEGIN PREPROCESSING DATA 

| 

4 

3 

UPDATE TDRS ORBIT FILE USING NEW TDRS VECTOR 


5 

5 

BEGIN ESTIMATION PROCESS 


6 

6 

PREDICT ONE-WAY DOPPLER OBSERVATIONS 

xf 

7 

7 

OUTPUT RESIDUAL REPORT 


a 

7 

OUTPUT DC SUMMARY AND STATISTICS REPORT 


9 

7 

OUTPUT STATUS (ACTIVITY LOG) 


10 

7 

OUTPUT PREDICTED ONE-WAY DOPPLER OBSERVATIONS 

- ' 

11 

7 

OUTPUT PREDICTED TARGET SPACECRAFT STATE VECTORS 

a 

12 

7 

OUTPUT PRIORITY MESSAGE 


13 

7 

GENERATE STATE VECTOR PREDICT TABLE 


14 

3 

UPDATE TDRS INTEGRATION START DATA WITH NEW PRE- 
DICTED TDRS STATE AFTER THIS MANEUVER 


15 

4 

PURGE DATA FILES 

* 

16 

5 

SUSPEND ESTIMATION 

* 

17 

5 

RESUME ESTIMATION 

m » 

18 

2 

BEGIN PROCESSING INPUT MESSAGES 

1 

u 

19 

5 

PERFORM HOUSEKEEPING IN ESTIMATOR (NECESSARY DUE TO 
USER SPACECRAFT MANEUVER) 


n r ’ 

4 

!* - 


m 

i 
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STATUS MESSAGES 

SYSTEM IDLE MESSAGE 

TIME-SCHEDULED 

REQUEST 

TRACKING INTERVAL 
TRACKING SCHEDULE 


ORIGINAL PAGE 13 
OF POOR QUALITY 


System event message, system 
error message, or information 
message (see Table B-2) 

PRIORITY MESSAGE stating that 
the system has an excessive 
amount of idle time 


Next action to be taken accord- 
ing to the schedules and the 
clock 

Next tracking interval over 
which one-way Doppler observa- 
tions will be predicted 

Tracking schedule for predict- 
ing one-way Doppler observa- 
tions (see Process 2) 
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Table B-2. Status Messages 


MESSAGE 

NUMBER 

GENERATIVE 

PROCESS 

MESSAGE 

TYPE® 

MESSAGE 

1 

2 


INPUT MESSAGE LOST 

2 

2 


INCOMPLETE INPUT MESSAGE 

3 

2 

EV 

OBSERVATION QUEUES FULL 

4 

2 

EV 

NEW TDRS VECTOR RECEIVED 

5 

2 

EV 

INITIALIZATION TABLE RECEIVED 

6 

2 

EV 

MANEUVER SCHEDULE RECEIVED 

7 

2 

EV 

ESTIMATION CONTROL PARAMETERS RECEIVED 

S 

2 

EV 

TRACKING SCHEDULE RECEIVED 

9 

2 

EV 

O MMAND RECEIVED 

10 

2 

IN 

NUMBER OF OBSERVATIONS RECEIVED 

11 

3 

EV 

TDRS ORBIT FILE UPDATED 

12 

3 

EV 

DATA PREPROCESSING COMPLETED 

13 

3 

IN 

NUMBER OF OBSERVATIONS WRITTEN TO OBSERVA- 
TIONS FILE 

14 

3 

ER 

ERROR IN TDRS PROPAGATION 

IB 

3 

ER 

NO DATA FOR TDRS ID 

16 

5 

ER 

ERROR IN TARGET SPACECRAFT PROPAGATION 

17, 

5 

ER 

TOO MANY OBSERVATIONS EDITED OUT 

18 

5 

ER 

NORMAL MATRIX CANNOT BE INVERTED 

19 

5 

IN 

NUMBER OF OBSERVATIONS EDITED 

20 

5 

EV 

ESTIMATION COMPLETED; NEW SOLUTION ATTAINED 

21 

5 

EV 

ESTIMATION COMPLETED; MAXIMUM ITERATIONS 
REACHED 

22 

6 

ER 

ERROR IN TDRS PROPAGATION 

23 

6 

ER 

ERROR IN TARGET SPACECRAFT PROPAGATION 

24 

. 6 

EV 

PREDICTION OF ONE-WAY DOPPLER OBSERVATIONS 
COMPLETED 

25 

7 

EV 

RESIDUAL REPORT OUTPUT 

26 

7 

EV 

DC STATISTICS AND SUMMARY REPORT OUTPUT 

27 

7 

EV 

STATUS (ACTIVITY LOG) OUTPUT 

28 

7 

EV 

STATE VECTORS OUTPUT 

29 

7 

EV 

PREDICTED ONE-WAY DOPPLER OBSERVATIONS 
OUTPUT 

30 

7 

EV 

PRIORITY MESSAGE OUTPUT 

31 

7 

EV 

STATE VECTOR PROPAGATED 

32 

7 

ER 

ERROR IN TARGET SPACECRAFT PROPAGATION 

33 

2 

EV 

INPUT CONTAINS DATA 

34 

2 

EV 

INPUT QUEUE FULL 

35 

2 

EV 

OBSERVATION QUEUES CONTAIN FULL DATA PASS 

36 

2 

EV 

MISCELLANEOUS CONSTANTS RECEIVED 

37 

2 

EV 

STATION CONSTANTS RECEIVED 

38 

2 

EV 

GEOPOTENTIAL TABLES RECEIVED 

39 

2 

EV 

ATMOSPHERIC DENSITY TABLE RECEIVED 

40 

2 

EV 

TIMING COEFFICIENTS RECEIVED 

41 

3 

EV 

TDRS INTEGRATION START DATA UPDATED 

42 

4 

EV 

DATA FILES PURGED 

43 

5 

EV 

HOUSEKEEPING COMPLETED 

44 

5 

ER 

NOT ENOUGH DATA FOR ESTIMATION 


a EV - SYSTEM EVENT; ER = ERROR; IN ■ INFORMATIVE. 
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B.2 DATA DICTIONARY FOR PROCESS 2: PROCESS INPUT MESSAGES 


ATMOSPHERIC DENSITY 
TABLES 


CODE 


CONSTANTS 


= Maximum and minimum density 

associated with altitude (100 
to 1000 kilometers) 

= Partition of executable code + 

partition name 

= MISCELLANEOUS CONSTANTS 

+ STATION CONSTANTS 

+ GEOPOTENTIAL TABLES 

+ TIMING COEB'FICIENTS 

+ ATMOSPHERIC DENSITY TABLE 


CONTROL COMMANDS 


DATA 


DIRECTIVES 


= Status request 

+ Start 

+ Stop 

+ Abort 

+ Suspend 

+ Continue 

+ Reboot 

+ Set clock 

= RAW OBSERVATION MESSAGES 

+ NEW TDRS VECTOR 

+ MANEUVER SCHEDULE 

+ TRACKING SCHEDULE 

+ INITIALIZATION TABLE 

+ CONSTANTS 

+ ESTIMATION CONTROL PARAMETERS 

= Defined in Process 1 (Table B-l) 
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ESTIMATION CONTROL 
PARAMETERS 


GEOPOTENTIAL TABLES 


INITIALIZATION TABLE 


INPUT MESSAGES 


Maximum iterations for estima- 
tion process 

+ Observation weignts 

+ Sigma multiplier for editing 

+ Convergence criteria 

+ Maximum divergent iterations 

+ Size of estimation time span 

+ Observation weights 

4- Residuals Report control switch 

+ DC Summary and Statistics 

Report control switch 

= Order of harmonic field for 

TDRS and target 

+ Degree of Harmonic field for 

both 

+ Point mass 

+ Zonal harmonic coefficients 

(Jl - Jl5> 

+ C harmonic coefficients 

(15-by-15) 

+ S narmonic coefficients 

(15-by-15) 

= A priori stats parameters 

+ A priori standard deviations 

+ Reference time 

+ Solve-f or/consider map 

= CONTROL COMMANDS + DATA + CODE 


INPUT OBSERVATION 

QUEUES = Usable bytes (see Appendix C) 

of the raw observation message, 
wnich are queued by type 
(1 = one-way TDRS; 2 = two-way 
TDRS? 3 = three-way TDRS? 

4 = one-way SRE; 5 = two-way 
SRE) 
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MANEUVER SCHEDULE 


(Maneuver time + spacecraft ID 
+ predicted position and veloc- 
ity) x 16 

MISCELLANEOUS 

CONSTANTS 

- 

Drag switch for target 


+ 

Solar radiation pressure switch 
for TDRS 



Sun and Moon switches for TDRS 
and target 


+ 

Integration stepsizes for botn 


+ 

Area of both spacecraft 


+ 

Mass of both spacecraft 


+ 

Solar flux constant 


+ • 

Solar radiation pressure con- 
stant 


+ 

Rotation rate of Earth 


+ 

Equatorial radius of Earth 


+ 

Flattening coefficient of Earth 


+ 

Speed of light 


+ 

Reference time of Julian date 


+ 

Radians-to-degrees conversion 
constant 


+ 

Pilot frequency 


+ 

Refraction switch 


+ 

Timing biases for TDRSS and 
target 


+ 

Time pad for predicting one-way 
Doppler 


+ 

State vector predict table time 
interval 


+ 

State vector output frequency 
in predict table 

RAM 

= 

Random-access memory 

RAvV OBSERVATION 

MESSAGE 


Raw observation in the univer- 
sal tracking data format (Ap- 
pendix C) 


B-8 


ORIGINAL PACE ic 
°P POOR QUALITY 


STATION CONSTANTS 

+ 

+ 

+ 

+ 

+ 

STATUS MESSAGES 

TIMING COEFFICIENTS = 


Total number of stations 
Station IDs 
Station positions 
Range bias 
Frequency bias 
Transponder delay 

Defined in Process 1 (Taole B-2) 

Coefficients of polynomials 
approximating USNO time differ- 
ence data covering at least 
1 year 


TRACKING SCHEDULE 

(FOR ONE-WAY DOPPLER) = (Start and end times of each 

tracking interval + TDRS 
ID + output frequency) x 16 
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B.3 DATA DICTIONARY 

FOR 

PROCESS 3: PREPROCESS DATA 

ACCEPTABLE OBSERVA- 
TION 

S 

Input observation that has the 
proper tracking configuration 
(i.e., right type, TDRS, sta- 
tion, ascending time order) 

CONSTANTS 

S5 

Defined in Process 2 (Sec- 
tion B.2) 

DIRECTIVES 

=3 

Defined in Process i (Taole B-l) 

INPUT OBSERVATION 
QUEUES 

= 

Defined in Process 2 (Sec- 
tion B.2) 

NEW TDRS VECTORS 

= 

Defined in Process 2 (Sec- 
tion B.2) 

OBSERVATION 

= 

Time tag 



Range measurement 


+ 

Doppler measurement 



Edit flags 


+ 

Ground antenna IDs 


+ 

Forward lin.< ID and TDRS/ground 
terminal (GT) carrier frequency 
ID 



Return link ID and TDRS/GT car- 
rier frequency ID 



TDRS frequency 


+ 

Access method 

OBSERVATION DATA 
TIME SPAN 

= 

Start and end times of data in 
observation queues 

PREDICTED TDRS 
VECTOR AFTER 
MANEUVER 

= 

Defined in Process 1 (Sec- 
tion 3.1) 

STATUS MESSAGES 

= 

Defined in Process 1 (Table B-2) 
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ORIGINAL PACEjS 

*>*; POOR QvJAulTY 


I 

I 

I 


TORS INTEGRATOR 
START DATA 


TDRS VECTOR 


3 TDRS position and velocity at 

final propagation time 

+ Pinal propagation time <T) 

+ TDRS ID 

+ Velocities and accelerations at 

time T-AT, T-2AT, T-3AT, 

T-4AT, T-5AT, T-6AT, T-7AT, 
T-8AT 

+ Save counter 

= TDRS position and reference 

time + TDRS ID 


ff* 

i 


U 


r 

d* 


-l 

-•{ 

w. 


n 


fit* 

i 


B-ll 


1 . 



SSSS3S& 


3.4 DATA DICTIONARY FOR PROCESS 4: MANAGE DATA BASE 


DIRECTIVE = Defined in Process 1 (Table B-l) 

LAST OBSERVATION 

TIME = Time tag of the last observa- 

tion in the file 


OBSERVATION 

OBSERVATIONS FILE 

OBSERVATION READ 
ADDRESS 


Defined in Process 3 (Sec- 
tion B.3) 

File containing up to 500 ob- 
servation pairs 


Location in memory of the ob- 
servation record that is to De 
read 


OBSERVATION WRITE 
ADDRESS 


STATUS MESSAGES 
TDRS ORBIT FILES 


TDRS READ ADDRESS 
TDRS REQUEST TIME 
TDRS VECTOR (S) 


TDRS WRITE ADDRESS 


Location in memory where the 
ooservation record is to be 
written 

Defined in Process 1 (Tabl-e B-2) 

Files containing TDRS vectors 
at an even time spacing over 
each observation time span for 
each TDRS 

Location in memory of the TDRS 
record that is to be read 

Reference time of the TDRS vec- 
tor (s) that are to be read 

TDRS vectors surrounding the 
TDRS request time that may be 
used for interpolation 

Location in memory where the 
TDRS vector is to oe written 
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a .3 DATA DICTIONARY 

BATCH ESTIMATION 
MATRICES 

COMPUTED OBSERVATION 

CONSTANTS 
DC STATISTICS 


DC SUMMARY 


DC SUMMARY AND 
STATISTICS REPORT 

DIRECTIVE 
EDITING STATISTICS 

ESTIMATION PARAM- 
ETERS 


ORIGINAL PACE.’ IV, 
OF POOR QUALITY 


FOR PROCESS 5: ESTIMATE STATE 


= Normal equation and matrix used 
to solve for the state correc- 
tion 

= OBSERVATION + computed range 

and Doppler based on the cur- 
rent state 

= Defined in Process 2 (Sec- 

tion B.2) 

= Current weighted rms 

+ Predicted weighted rms 

+ Previous weighted rms 

+ Smallest weighted rms 

+ Relative change in rms 

+ Penalty 

+ Convergence message 

+ Start time 

+ End time 

= Previous state 

+ Current state 

+ STATE CORRECTION 

+ Standard deviations 

+ A priori state 

= DC STATISTICS + EDITING 

STATISTICS + DC SUMMARY 

= Defined in Process 1 (Taole 3-1) 

= Number of ooservations available 

+ number of observations used 
+ number of ooservations 
edited by n sigma editing 

SOLVE -FOR PARAMETERS 

+ ESTIMATION CONTROL PARAMETERS 

(see Process 2 (Section B.2)) 
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NEW STATE SOLUTION 

LAST OBSERVATION 
TIME 

OBSERVATION 

OBSERVATION EDIT 
TAGS 

OBSERVATION PARTIALS 

OBSERVATION RESIDUAL 

OBSERVATION TIME 
SOLVE-FOR PARAMETERS 


STATE CORRECTION 
VECTOR 


STATE TRANSITION 
MATRIX 

STATUS MESSAGES 
TDRS REQUEST TIME 

TARGET STATE VECTOR 


ORIGINAL PAG2S3 
OF POOR QUALITY 


UPDATED STATE VECTOR when tne 
estimation nas converged 


Defined in Process 4 (Sec- 
tion B.4) 

Defined in Process 3 (Sec- 
tion B.3) 


= Indicator associated with each 

computed observation that shows 
whether the residual is witnin 
a specified range 

= Partial derivatives of the oo- 

servations (range and Doppler) 
with respect to the solve-for 
state at the observation time 

= Difference between tne observed 

and computed measurements (O-C) 

= Time tag on observation 

= Solve-for state + standard de- 

viations 

+ Observation weights 

+ Solve-for/consider map 

+ A priori state 


Estimated correction for eacn 
state parameter at epoch 


Matrix used to propagate the 
observation partials from the 
observation time to epoch 

Defined in Process 1 (Table B-2) 

Defined in Process 4 (Sec- 
tion B.4) 

Target spacecraft position and 
velocity at tne ooservation time 
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TDRS VECTOR (S) 
UPDATED STATE 


= Defined in Process 3 (Sec- 
tion B.3) 

VECTOR = (Solve- for state + state cor- 
rection) 


OfflGINM- w ise 'S 
OF POOR QUAtfTf 


S.6 DATA DICTIONARY FOR PROCESS 6: PREDICT ONE-WAY DOPPLER 

SBSBRVKITO'MS 


CONSTANTS 

DIRECTIVE 

NEXT OBSERVATION 
TIME 


Defined in Process 2 (Sec- 
tion B.2) 

Defined in Process 1 (Table B-l) 


Time at which next observation 
will be predicted 


ONE-WAY PREDICTED 
DOPPLER OBSERVATIONS 


NEW STATE SOLUTION 


PROPAGATED TDRS 
VECTOR 


STATUS MESSAGE * 


Doppler measurement t station 
ID + TDRS ID + time tag 

Defined in Process 5 (Sec- 
tion B.5) 


TDRS position and velocity 
propagated ;o ooservation time 

Defined in Process 1 (Table B-2) 


TARGET STATE VECTOR = Position and velocity of target' 

spacecraft propagated to next 
observation time 


TDRS VECTOR 


Defined in Process 3 (Sec- 
tion B.3) 


TRACKING INTERVAL 


Defined in Process 1 (Sec- 
tion B.l) 
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B . 7 DATA DICTIONARY FOR PROCESS 7: PERFORM OUTPUT 


ACTIVITY LOG 
CONSTANTS 

DC RESIDUALS REPORT 

DC SUMMARY AND 
STATISTICS REPORT 

DIRECTIVES 

ENCODED DATA MESSAGE 


Defined in Process I (Sec- 
tion B.l) 

Defined in Process 2 (Sec- 
tion B.2) 

Defined in Process 5 (Sec- 
tion B.5) 


Defined in Process 5 (Sec- 
tion B.5) 

Defined in Process 1 (Table B-l) 

Data encoded in output message 
format 


ENCODED PRIORITY 

MESSAGE - PRIORITY MESSAGE encoded in 

output message format 


ENCODED REPORT MES- 
SAGE 

NEW STATE SOLUTION 


One part of the report encoded 
in output message format 

Defined in Process 5 (Sec- 
tion B.5) 


ONE-WAY PREDICTED 

DOPPLER OBSERVATIONS = Defined in Process 6 (Sec- 
tion B.6) 


OUTPUT MESSAGES 


All messages output from AODS 
in a form tnat can be put on 
the transmission line 


OUTPUT TARGET STATE 
VECTORS 


RESIDUAL REPORT 
STATUS MESSAGES 


Taole of position and velocity 
vectors of the target space- 
craft tnat are time tagged; tne 
vectors are generated at a 
specified frequency over a 
specified time interval 

Defined in Process 5 (Sec- 
tion B.5) 

Defined in Process 1 (Table B-2) 
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APPENDIX C - INPUT AND OUTPUT MESSAGE FORMATS 

Tnis appendix contains the input and output message formats 
through wnich AODS will communicate with the external 
world. Figure C-l shows the standard data transmission for- 
mat tnat will be used for both input and output. A defini- 
tion of terms used in Figure C-l and throughout the appendix 
is provided below: 



Term 

Definition 

J 

Transmission 

Set of one or more blocks of data that are 


. 

transmitted contiguously. A transmission is 
always terminated by an end-of-transmission 



+ 


record (all Is) 


Block 

Set of one or more data records that contain 

i 

i 


the same type of data 

* 

Record 

A 256-byte record containing a header 
(20 bytes) and one or more frames of data 



(see Figure C-2) 

- 

Frame 

One entity of data 


Header 

A 20-byte header frame that describes tne 
contents of the record 

ft 

C.l INPUT (UPLINK) MESSAGE FORMATS 


Tnis section contains the input message formats througn 
wnicn data and commands will *)e uplinked to AODS. Sec- 
tion C.1.1 specifies the format of the record header (first 
20 bytes) , which is common to all input records. Sec- 
tion C.1.2 through C.1.13 specify tne message block attri- 
outes and the frame format for each type of input data and 
command. 
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266 BYTES 


RECORD 1, BLOCK 1, TRANSMISSION 1 


BLOCK 1 < 


RECORD 2, BLOCK 1, TRANSMISSION 1 


RECORD n, BLOCK 1, TRANSMISSION 1 


RECORD 1, BLOCK 2, TRANSMISSION 1 


BLOCK 2 / 


RECORD 2, BLOCK 2, TRANSMISSION 1 


RECORD m, BLOCK 2, TRANSMISSION 1 


\ TRANSMISSION 


BLOCK j 



RECORD 1, BLOCK j, TRANSMISSION 1 




RECORD 2, BLOCK ), TRANSMISSION 1 

• 

. 

• 

• 


RECORD 1, BLOCK \, TRANSMISSION 1 




END OF TRANSMISSION 


Figure C-l. Data Transmission Format 
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HEADER 
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FRAME FORMATS 

Vair iable Type Dimension Description 


XDSC 

Byte 

1 

Spacecraft ID 

IDEX 

Byte 

1 

Experiment ID 

INTYPE 

Byte 

1 

Type of input 
= 1, data 
= 2, code 
= 3, commands 

INDATA 

Byte 

1 

Type of data: 


= 1, raw ooservations 

= 2, initialization table 

= 3, new TDRS vector 

= 4, estimation control 

parameters 

= 5, maneuver schedule 

= 6, tracking schedule 

= 7, miscellaneous constants 

= 8, station constants 

= 9, geopotential tables 

= 10, atmospneric drag 
= 11, timing coefficients 


NBLOCK 

Byte 

1 

Running number of record in 
block 

MBLOCK 

Byte 

1 

Total number of records in 
block 

NTRAN 

1*2 

1 

Running number of record in 
transmission 

MTRAN 

1*2 

1 

Total number of records in 
transmission 

NSIZE 

1*2 

1 

Number of bytes used in record 

IT RAN 

R*8 

1 

Time of transmission (seconds 
from reference time) 
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C.1.2 RAW OBSERVATION DATA MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 £came = 1 caw obsecvation (75 bytes) 


* 

1 

1 

FRAME 

Data 

record 

256 

256 

block = 
FORMAT 3 

F ield 

= header + 3 frames + fill 
= 20 + 3 x 75 + fill 
= 245 + fill 

1 or more records (defined during transmission) 

• 

« 

Reduced 

Observation 

Format^ Contents of Field Type Bytes 


Bytes 

1-5 

H 

Fill 

- 

0 

«* *■ 

Byte 

6 

B 

Last two digits of 
current year 

Byte 

1 

j 

\ 

j 

Bytes 

7-8 

B 

Support Identifica- 
tion Code (SIC) of 
user or TDRS pro- 
viding return link 


0 

ltd 

m if 

Bytes 

9-10 

B 

Vehicle ID (VID) of 
target 

— 

0 

j 

'J 

Bytes 

11-14 

B 

Time tag (seconds 
of year) 

Real 

4 

Hi ■■ 

i 

*» 

'Bytes 

15-18 

B 

Time tag (microsec- 
onds of second) 

Real 

4 

* * 

1 

Bytes 

19-22 

B 

Return link azimuth 
angle 

— 

0 

u 

rt m 

3y tes 

23-26 

B 

Return link eleva- 
tion angle 


0 

i 

\ 

a 

Bytes 

27-32 

B 

Range measurement 
nanoseconds ) 

Real 

8 

» r 

j 

Bytes 

33-38 

B 

Doppler count 

Real 

8 

j 

Bytes 

39-40 

H 

Fill (00 i6 ) 

- 

0 

'j 

** 

a This 

is the 

universal 

tracking data format, 

taken from 



Reference 9. 

H = hexadecimal, B = binary, D = discrete. 
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Data Field 

Format 
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Contents of Field 

Reduced 
Observation 
Type Bytes 

u 

* 

a a 

Bytes 41-44 

B 

Reference frequency 
used in Doppler ex- 
traction 

Integer 4 

\ 


Byte 45 

H 

Fill (60i6) 

0 

« * 

Byte 46 

B 

TDRS ground antenna 
ID associated with 

Byte 1 

o - 


TDRS providing for- 
ward link 


Byte 47 

H 

Fill (60i5) 

- 

0 


Byte 48 

B 

Return link ground 
antenna ID associ- 
ated with TDRS 

Byte 

1 


Byte 49 


TDRS IDs: 




Bits 8-5 

H 

Forward link 

Byte 

1 


Bits 4-1 

H 

Return link 

Byte 

1 


Byte 50 






Bits 8-4 

B 

Multiple-access 
return link ID; 
binary ID of radio 
frequency (RF) 
Beam-forming 
equipment 


0 * 


Bit 3 

B 

TDRS tracking data 
only indicator 


0 


Bits 2-1 

B 

Tracking service 
configuration 


0 


Byte 51 


Data validity field: 




Bit l 

D 

Validity of range 

Byte 

1 


Bit 2 

D 

Validity of 
Doppler 

Byte 

1 


Bit 3 

D 

Validity of re- 
turn link antenna 
angles 


0 
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Reduced 

Observation 


Data 

Field 

Format 

Contents of Field 

Type 

Bytes 

Byte 

52 

H 

Frequency band 


0 


(most significant 
digit (MSD) and 
service type (least 
significant digit 
(LSD) ) 


Byte 53 

MSD 

H 

Tracker type 

Byte 

1 

Bit 4 

D 

End of track 

Byte 

1 

Bit 3 

D 

0 indicates data in 
sample rate field 
is seconds between 
tracking samples 

Byte 

1 

Byte 53 , 
bit 2 
through 
byte 54, 
Dit 1 

B 

Seconds between 
tracking samples 

R 

4 

Byte 55 

Bit 8 

D 

TDRS orientation 
validity 

— 

0 

Bit 7 

D 

RF beam orienta- 
tion validity 

- 

0 

Bits 6-4 

B 

Forward link ID 
and TDRS/GT 
carrier fre- 
quency ID 

Byte 

1 

Bits 3-1 
Byte 56 

B 

Return link ID 
and TDRS/GT 
carrier fre- 
quency ID 

Byte 

1 

Bits 6-5 

D 

User bit rate 
indicator 

— 

0 

Bits 4-1 

B 

TDRS tracking 
data transponder 
ID 


0 

Bytes 57-58 

B 

TDRS yaw 

- 

0 

Bytes 55-60 

B 

TDRS roll 

- 

0 
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Reduced 

Observation 


Data Field 

Format 

Contents of Field 

Type 

Bytes 

Bytes 61-62 

B 

TDRS pitch 

- 

0 

Bytes 63-65 

H 

RF beam azimuth 

- 

0 

Bytes 66-68 

H 

RF beam elevation 

- 

0 

Bytes 69-75 

H 

Fill (00 16 , 
04 16f 0F 16 ) 

- 

0 
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C.1.3 INITIALIZATION TABLE INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = 1 initialization table (188 bytes) 

1 record = 1 header + frame + fill 
256 = 20 + 188 4- fill 
256 = 208 + fill 

1 block = 1 record 


FRAME FORMAT 
Variable 

m 

• 

Type 

Dimension 

Description 

REFTM 

R* 8 

1 

Reference time 

REFAPR 

R*8 

10 

A priori state vector 

REFSTD 

R* 8 

10 

A priori standard de- 
viation 

MAP 

1*2 

10 

Solve-for consider map 
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C.1.4 NEW TDRS VECTOR (S) INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = new TDRS vector for 1 TDRS (60 bytes) 

1 record = header + 1 frame + fill 
256 = 20 + 60 + fill 
256 = 80 +' fill 

1 block = 1 to 3 records (defined at transmission) 


FRAME FORMAT 
Variable 

• 

■ 

Type 

Dimension 

Description 

TDRTIM 

R* 8 

1 

TDRS reference time 
( YYMMDDHHMMSS . S3 ) 

TDRSX 

R*8 

6 

New TDRS position and 
velocity vectors 

IDTDRS 

1*2 

1 

TDRS ID 

INTYPE 

1*2 

1 

Type of input vector: 

= 0, new estimate of 
TDRS vector 

= 1, update to previou 
TDRS maneuver 
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C.1.5 ESTIMATION CONTROL PARAMETERS INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = estimation control parameters set (66 bytes) 

1 record = 1 frame + fill 
256 = 66 + fill 

1 block = 1 record 


FRAME FORMAT: 


Variable 

Type 

Dimension 

Description 

DCS PAN 

R*4 

1 

Estimation time span 
(size of batch of data 
in seconds) 

SPARE 

1*2 

1 

Spare 

SIGMA 

R*4 

1 

Sigma multiplier for 
editing 

CONVRG 

R*8 

1 

Convergence criteria 

MAXITR 

1*2 

1 

Maximum number of iter- 
ations to be performed 

MAXDIV 

1*2 

1 

Maximum number of di- 
vergent iterations 
allowed 

OBSSTD ( I , J) 

R* 4 

2,5 

Observtion standard de- 
viations : 


I = measurement type 
(= 1, range; = 2, 
Doppler) 

J = observation type 
(= 1, one-way TDRS3 ; 

= 2, two-way TDRS ; 

= 3, three-way TDRSS 
= 4, one-way SRE; 

= 5, two-way SRE) 

IROUT 1*2 1 Residual Report output 

control switch: 

= 0, no report 
= 1, report generated 
after last itera- 
tion on a batch of 
data 

= 2, report generated 
after first and 
last iterations 
on a batch of data 
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Variable 

IDCOCJT 


Type Dimension Description 

1*2 1 DC Summary and Statistics 

Report output control switch: 
= 0, no report 
“ 1, report generated 
after last itera- 
tion on a batch 
of data 

= 2 , report generated 

after every itera- 
tion 
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C.1.6 MANEUVER SCHEDULE INPUT MESSAGE 


MESSAGE BLOCK ATTRIBUTES; 


1 frame 

= 1 scheduled 

maneuver 

(58 bytes) 

1 record 
256 
256 

= header + 4 
= 20 4- 232 + 
= 252 4 fill 

frames 4 
fill 

fill 

1 block 

= 4 records 



FRAME FORMAT 

• 

• 



Variable 


Type Dimension 

Description 

TIM01 


R*8 

1 

Time of maneuver 
( YYMMDDHHMMSS . SS ) 

XM01 


R*8 

6 

Predicted state (posi- 
tion and velocity) 
after maneuver 

MS I DO 1 


1*2 

1 

ID of maneuvered space 
craft ( TDRS ID for 
TDRS, SIC and .VI D for 
user spacecraft) 



'*« 

f 




ORK»^> " c y 

OF POOR QUAUnV 


G.1.7 TRACKING SCHEDULE INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = schedule for 1 tracking interval (22 bytes) 

1 record = header + 8 frames + fill 
256 = 20 + 8 x 22 + fill 



256 = 20 + 176 + fill 
256 = 196 + fill 

1 block = 2 

records 

FRAME FORMAT: 


Variable 

Type 

Dimension 

STIME 

R*8 

1 

ETIME 

R* 8 

1 

TDRSID 

1*2 

1 

OBSFRQ 

* 

R*4 

1 


Description 

Start time of tracking 
interval ( YYMMDDHHMMSS . SS ) 

End time of tracking in- 
terval (YYMMDDHHMMSS.SS) 

ID of TORS to be used for 
one-way Doppler predic- 
tion during this interval 

Observation' frequency 
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C.1.8 MISCELLANEOUS CONSTANTS INPUT MESSAGE 


MESSAGE BLOCK ATTRIBUTES: 


1 frame 

= set of constants 

(236 bytes) 

1 record 

= header + 

i frame 

= 256 

1 block 

= 1 record 



FRAME FORMAT 

• 

• 



Var iaole 

Type Dimension 

Description 

NDRAG 

Byte 

1 

Drag switch 3 for target 

NSOLRD 

Byte 

1 

Solar radiation pressure 
switch 3 for TDRS 

NSUN(I) 

Byte 

2 

Sun switches: 3 
1=1, target 
1=2, TDRS 

NOOM(I) 

Byte 

2 

Moon switches: 3 
1=1, target 
1=2, TDRS 

STEPS Z (I) 

R*4 

2 

Integration stepsizes: 
1=1, target 
1=2, TDRS 

SCAREA(I) 

R* 4 

2 

Area of spacecraft: 
1=1, target? 
1=2, TDRS 

SCMASS (I) 

R*4 

2 

Mass of spacecraft: 
1=1, target 
1=2, TDRS 

5FLUX 

R*4 

1 

Solar flux value 

SOLRAD 

R* 4 

1 

Solar radiation pressure 

REFJUL 

R* 3 

1 

Reference time of Julian 
date 

OMEGA 

R*8 

1 

Rotation rate of Eartn 

EQTRAD 

R*8 

1 

Equatorial radius 

FLAT 

R*a 

1 

Flattening coefficient 

PI 

R* 8 

1 

TT 

Switches : 

1 = on , 0 = 

off. 
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Var iaole 

Type 

Dimension 

Description 

VLITE 

R*8 

1 

Speed of lignt 

RTD 

R*8 

1 

Radians-to-degrees con- 
version constant 

TPREQ(I) 

R*8 

5 

Table used to compute 
pilot frequency for the 
following access methods: 
1=1, multiple-access 
(MA) 

1=2, S-band single- 
access link 1 (SSAl) 
1=3, SSA2 

1 = 4, K-band single-, 
access link 1 (KSAl) 
1=5, KSA2 

TBI ASR ( T ' 

R*8 

3 

Timing bias for TDRS : 
1=1, TDRS I 
1=2, TDRS II 
1=3, TDRS III 

TBIASS 

R*8 

1 

Timing bias for user 
spacecraft 

IPRAC 

1*2 

1 

Refraction switch: 
=0, off 
= 1, on 

TPAD 

R*4 

1 

Time pad for output of 
predicted one-way 
Doppler data (minutes) 

SPINT 

R*4 

1 

State vector predict 
taole size (minutes) 
(default = 30 minutes) 

SPFREQ 

R*4 

1 

State vector frequency 
in predict table (min- 
utes) (default = 1 min- 
ute) 

CS PARES 

R* 4 

14 

Spare locations for con- 
stants 
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C.1.9 STATION PARAMETERS INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 


Set of constants = 1002 bytes 


Record 

1 

= header 

4 * 

frame 

1 

(234 

bytes) = 254 

bytes 

4 - 

fill 

Record 

2 

= header 

•f 

frame 

2 

(192 

bytes) = 212 

bytes 

4 - 

fill 

Record 

3 

= header 

4 “ 

frame 

3 

(192 

bytes) = 212 

bytes 

4 - 

fill 

Record 

4 

= header 

4 * 

frame 

4 

(192 

bytes) = 212 

bytes 

4 * 

fill 

Record 

5 

= header 

4 - 

frame 

5 

(192 

bytes) = 212 

bytes 

4 - 

fill 


1 blocx = 5 records 


FRAME 1 FORMAT: 


Variable 

Type 

Dimension 

Description 

NSTA 

1*2 

1 

Total number of stations 
used 

IDSTA(J) 

1*2 

20 

Station IDs in order cor 
responding to positions 

ST AT ( I , J) 

R* 8 

6,4 

Constants for station J, 
wnere J = 1 through 4: 


1=1, Earth-fixed 
position component-X 
1=2, Earth-fixed 
position component-Y 
1=3, Earth-fixed 
position component-2 
1=4, range bias 
1=5, frequency bias 
1=6, transponder 
delay 

FRAME 2 FORMAT: 


Variable 


Type Dimension 


Description 


ST AT ( I , J) R*8 


6,4 Constants for station 

J, wnere J = 5 througn 
8 (see frame 1 format, 
above) 
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FRAME 3 FORMAT: 


Variable Type 

Dimension 

Descr iption 

ST AT ( I , J) R*8 

6,4 

Constants for station 
J, where J = 9 through 
12 (see frame 1 format, 
above) 

FRAME 4 FORMAT: 

Variable Type 

Dimension 

Description 

STAT ( I , J) R*8 

6,4 

Constants for station 
J, where J = 13 througn 
16 (see frame 1 format, 
above) 

FRAME 5 FORMAT: 

Variable Type 

Dimension 

Description 

STAT ( I , J) R* 8 

6,4 

Constants for station 


J, where J = 17 through 
20 (see frame 1 format, 
above) 




e 
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C.1.10 GEOPOTENTIAL TABLES INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 


Total set of constants = 1004 bytes 


Record 

1 = header 

+ 

frame 

1 

(232 

bytes) = 256 

bytes 

Record 

2 = header 


frame 

2 

(200 

bytes) = 220 

bytes 

Record 

3 = header 

+ 

frame 

3 

(200 

bytes) = 220 

bytes 

Record 

4 = header 

+ 

frame 

4 

(200 

bytes) = 220 

bytes 

Record 

5 = header 


frame 

5 

(200 

bytes) = 220 

bytes 


1 block = 5 records 


FRAME 1 

FORMAT : 



Variable 

Type 

Dimension 

Descr iption 

MORD(I) 

Byte 

2 

Order of harmonic field 
I = 1, target 
1=2, TDRS 

MDEG (I) 

Byte 

2 

Degree of harmonic field 
1=1, target 
1=2, TDRS 

GM 

R*8 

1 

Point mass 

XJ 

R*4 

15 

Zonal harmonics (Jj_ 
through J]_ 5 ) 

CS 

R*4 

40 

First 40 C- and S- 
harmonic coefficients 
(C-harmonic coeffi- 
cients in lower trian- 
gle of 15-bv-16 matrix; 
S-harmonic coefficients 
in upper triangle of 
15-by-16 matrix) for 
15-by-15 geopotential 
model 

FRAME 2 

FORMAT : 



Var iaole 

Type 

Dimension 

Description 

CS 

R*4 

50 

Next 50 C- and S- 


harmonic coefficients 
(C-harmonic coeffi- 
cients in lower trian- 
gle; S-harmonic co- 
efficients in upper 
triangle) of 15-by-15 
model 
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FRAME 3 FORMAT: 

Vac iablg Type Dimension Description 

CS R*4 25 Next 50 C- and S- 

narmonic coefficients 
(G-harmonic coeffi- 
cients in lower trian- 
gle; 3-harmonic 
coefficients in upper 
triangle) of 15-by-15 
model 


FRAME 4 FORMAT: 
Variable Type 

CS R*4 


Dimension 

50 


FRAME 5 FORMAT: 

Va r iaole Type Dimension 

CS R*4 50 


Description 

Next 50 C- and S- 
harmonic coefficients 
(C-harmonic coeffi- 
cients in lower trian- 
gle; S-harmonic 
coefficients in upper 
t r iangle) of 15-by-15 
model 


Descr iption 

Lasc 50 C- and S- 
narmonic coefficients 
(C-narmonic coeffi- 
cients in lower tri- 
angle; S-harmonic 
coefficients in upper 
triangle) of 15-by-15 
model 
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C.1.11 ATMOSPHERIC DENSITY TABLES INPUT MESSAGE 


MESSAGE BLOCK 

ATTRIBUTES : 


TOTAL SET 

OF DATA 

= 662 bytes 

Record 1 = 
Record 2 = 
Record 3 = 

Header 

header 

header 

+ frame 1 
+ frame 2 
+ frame 3 

(234 bytes) = 254 + fill 
(224 bytes) = 244 + fill 
(144 bytes) = 164 + fill 

1 BLOCK = 

3 records 


FRAME 1 FORMAT 

• 

• 



Variable 

TYPe 

Dimension 

Description 

NDENS 

1*2 

1 

Number of entries in den- 
sity table 

NALT(J) 

1*2 

60 

Altitude associated with 
density intervals (in 
ascending order) 

DENSTY ( I , J) 

R*4 

2,14 

First 14 intervals in 
density table: 

1=1, minimum density 
associated witn NALT(J) 
1=2, maximum density 
associated with NALT(J) 

FRAME 2 FORMAT 




Var iaole 

Type 

Dimension 

Descr iption 

DENSTY ( I, J) 

R*4 

2,28 

Next 28 intervals in den- 
sity table 

FRAME 3 FORMAT 

: 



Var iaole 

Type 

Dimension 

Description 

DENSTY ( I, J) 

R*4 

2,18 

Last 18 intervals in den- 


sity fcaole 
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C.1.12 TIMING COEFFICIENTS INPUT MESSAGE 

MESSAGE BLOCK ATTRIBUTES: 

1 frame = total set of data (226 bytes) 
1 record = header + 1 frame + fill 
256 = 20 + 226 
256 = 246 + fill 

1 block = 1 record 


FRAME FORMAT: 
Variable 

Type 

Dimension 

Description 

NDAYS 

1*2 

1 

Number of polynomials 




used in TCOEFF 

TCOEFF ( I , J) 

R*4 

7,8 

Coefficients of polyno 


mials approximating USNO 
time difference data: 
1=1, modified Julian 
date associated with 
polynomial J 
1 = 2, coefficient a^j. 
in polynomial J 
1 = 3, coefficient a^ 
in polynomial J 
1 = 4, coefficient a ^ 3 
in polynomial J 
1 = 5, coefficient a^ 
in polynomial J 
1 = 6, coefficient aj _5 
in polynomial J 
1=7, coefficient aj_g 
in polynomial J 
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C.1.13 CONTROL COMMAND INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES : 


1 frame - 1 command (202 bytes) 

1 record = header + 1 frame = 20 4- 202 + fill = 222 + fill 
1 block = 1 record 

FRAME FORMAT: 


Variable Type Dimension 


Description 


ICTYPE 


1*2 1 


COMMAND (I) Byte 200 


Type of command: 

= 1, reboot 
= 2 , abort 
= 2 , stop 
=’ 4, start 
= 5, suspend 
= 6, continue 
= 7, status request 
= 8, set clock 

Contents of command (de- 
pends on type of command) 
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C. 2 OUTPUT (DOWNLINK) MESSAGE FORMATS 

This section contains the output message formats through 
which data, reports, and informative messages will be down- 
linked from AODS. Section C.2.1 specifies the format of the 
record header, which is common to all output records. Sec- 
tions C.2.2 through C.2.8 specify the message block attri- 
butes and frame formats for each type of output data, 
report, and message. 
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C.2.2 HEADER 
FRAME FORMAT: 
Variable Type 

Dimension 

Description 

IDSC 

Byte 

1 

Spacecraft ID 

IDEX 

Byte 

1 

Experiment ID 

OUTYPE 

Byte 

1 

Type of output: 

= 1, spacecraft vectors 
= 2, Doppler observa- 
tions 

= 3, error message 
= 4, activity log 
= 5, DC Summary and 

Statistics Report 
= 6, DC Residuals Report 


Byte 

1 

Blank 

NBLOCK 

1*2 

2 

Running number of rec- 
ords in a block 

NTRAN 

1*2 

2 

Running number of rec- 
ords in a transmission 

NS IZE 

1*2 

2 

Re_cord size in bytes 


1*2 

2 

BlanK 

TTRAN 

R*8 

8 

Time of transmission 
(seconds from reference 
time) 


I 
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C.2.3 OUTPUT USER SPACECRAFT STATE VECTORS 
MESSAGE BLOCK ATTRIBUTES: 


I frame 

= 1 state vector (56 

bytes) 


1 record 
256 
256 

= header + 4 frames 
= 20 + 224 + fill 
= 244 + fill 

+ fill 


1 olock 

= 1 or 

more records 



FRAME FORMAT 

• 

• 




Variable 

Type 

Dimension 

Description 


TTAG 

R*8 

1 

Time tag 


PVEC 

R*8 

3 

Position vector (x, 

Yf z) 

WEC 

R*8 

3 

Velocity vector (x, 

y, z) 
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C.2.4 OUTPUT ONE-WAY DOPPLER OBSERVATIONS 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = 1 observation (22 bytes) 

1 reco- ‘ neader + 10 frames + fill 
2 20 + 220 + fill 

25b = 240 + fill 

1 block = 1 or more records 


FRAME FORMAT 
Variable 

• 

m 

Type 

Dimension 

Description 

OBTYPE 

Byte 

1 

Observation type: 

= 1, TDRSS one-way 
= 4, S-band on'e-way 

IDTDRS 

Byte 

1 

TDRS ID 

IDSTAF 

1*2 

1 

Forward link station ID 

IDSTAR 

1*2 

1 

Return link station ID 

OBTIME 

R* 8 

1 

Time tag 

DOPLR1 

R* 8 

1 

Doppier observation 
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C.2.5 OUTPUT ERROR MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = 1 error message (46 bytes) 

1 record = header + 1 frame + fill 
256 = 20 + 46 + fill 
256 = 66 + fill 

1 block = 1 record 


FRAME FORMAT: 




Variable 

Type 

Dimension 

Description 

TERR 

R*8 

1 

Time of error 

ERRMSG 

Byte 

38 

Message 
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29 
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C.2.7 DC SUMMARY AND STATISTICS REPORT 
MESSAGE BLOCK ATTRIBUTES: 

Whole report = 524 bytes 


Record 

1 = header + 

frame 

1 

+ 

fill = 20 

+ 

160 

+ 

fill = 256 

Record 

2 = header + 

frame 

2 

+ 

fill » 20 

+ 

160 

+ 

fill = 256 

Record 

3 = header + 

frame 

3 

+ 

fill = 20 

+ 

184 

+ 

fill = 256 

1 block 

= record 1 + 

record 

2 

+ record 

3 = 

> 3 

records 


FRAME 1 FORMAT: 


Variable 

Type 

Dimension 

Description 

TEPOCH 

R*8 

1 

Epoch 

STIME 

R*8 

1 

Start time of estima- 
tion data span 

ETIME 

R*8 

1 

End time of estimation 
data span 

RMS CNR 

R*8 

1 

Current weighted rms 

RMS P RE 

R*8 

1 

Predicted weignted rms 

RMSLST 

R*8 

1 

Previous weighted rms 

RMS MIN 

R*8 

1 

Smallest weighted rms 

RMSCHG 

R*8 

1 

Relative change in rms 

PENLTY 

R*8 

1 

Penalty 

CONVRG 

R*8 

1 

Convergence criteria 

XPREV 

R* 8 

10 

Previous state vector 

FRAME 2 : 

FORMAT : 



Var iaole 

Type 

Dimension 

Description 

XCURR 

R*8 

10 

Current state vector 

XAPR 

R*8 

10 

A priori state vector 
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FRAME 3 FORMAT : 


Variable 

Type 

Dimension 

Description 

XSTD 

R* 8 

10 

Standard deviations for 
state vector 

XUPD 

R* 8 

10 

State correction vector 

XSTATE 

1*2 

10 

Parameter numbers 

NSTATE 

1*2 

1 

Number of solve-for 
parameters 

NTOTAL 

1*2 

1 

Total number of obser- 
vations availaole 

NUSED 

1*2 

1 

Number of observations 
used 

NITER 

1*2 

1 

Iteration number 

N BATCH 

1*2 

1 

Batch number 
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C.2.8 DC RESIDUALS REPORT 
MESSAGE BLOCK ATTRIBUTES: 

1 frame = 1 line of report (48 bytes) 

1 record = header + 4 frames + fill 
256 = 20 + 192 + fill 
256 = 212 + fill 

1 block = 125 records 


FRAME FORMAT 

• 



Variable 

Type 

Dimension 

Descr iption 

IOBTYP 

Byte 

1 

Observation type: 

= 1, TDRSS one-way 
= 2, TDRSS two-way 
= 3 , TDRSS hybrid 
= 4, S-band one-way 
= 5, S-band two-way 

IEDIT ( I) 

Byte 

2 

Edit flag (I = 1, 
range; 1=2, Doppler) : 
= 0, not edited 
= 1, edited by DC 
= 2, edited during pre- 
processing 

ITDRSF 

Byte 

1 

TDRS ID (forward link) 

ITDRSR 

Byte 

1 

TDRS ID (return 1 i n k ) 

ISTATF 

Byte 

1 

Forward link station ID 

ISTATR 

Byte 

1 

Return link station ID 

IS PARE 

Byte 

1 

Spare location 

OBTIME 

R* 8 

1 

Time tag 

OBS ( 1) 

R* 8 

1 

Computed range observa- 
tion 

OBS ( 2) 

R* 8 

1 

Computed Doppler obser- 
vation 

RES ID ( 1) 

R*4 

1 

Range residual 

RESID ( 2) 

R* 4 

1 

Doppler residual 

RTS ( 1) 

R* 4 

1 

Ratio to sigma for 
range (range/standard 
deviation) 

RTS ( 2) 

R* 4 

1 

Ratio to sigma for 


Doppler ( Doppler/stand- 
ard deviation) 
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P ROCEDURES FO R MODIFYING AODS REQUIREMENTS 


Since a formal methodology was used to define the AODS re- 
quirements, they are easily modified. Three parts of the 
requirements definition could change: (1) data, (2) proc- 

esses, and (3) functional requirements. A change in one of 
these could, but would not necessarily, affect the other 
two. To ensure that all effects of a requirements modifica- 
tion are made apparent, the changes should be made as de- 
scribed below. 

To cnange a data definition, the data item should be located 
in the data dictionary (Appendix 13) and modified. Through 
the data dictionary, the processes that act upon that data 
item should be located and changed if necessary. The func- 
tional requirements affected can then be located through the 
Process/Requirements Map (Table 2-2) and changed where nec- 
essary. 

To modify a process definition, the process should be lo- 
cated in the data flow diagrams to determine whether the 
definition of any of its associated data flows is impacted. 
If so, the appropriate change (s) should be made in the data 
dictionary. Also, the functional requirements that are af- 
fected should be located through the Process/Requirements 
Map (Table 2-2) and modified where necessary. 

To modify a functional requirement, the processes affected 
snould oe located througn tne Requirement/Processes Map 
(Table 2-1) and modified where necessary. Any data flows 
that are affected can then be located and modified accord- 
. ingly in the data dictionary. 
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APPENDIX E - RECOMMENDED ESTIMATION LOGIC FOR AODS 


This appendix contains a memorandum sent from the Orbital 
Mechanics Section at GSFC to the Head of the Systems Devel- 
opment Branch at GSFC describing the recommended estimation 
logic for AODS, 


E-l 


January 8, 1981 


TO: 582/Head, Systems Development and Analysis Branch 

FRQM: 582.2/Orbital Mechanics Section 

(' 

SUBJECT: Recommended Estimation Logic For AODS 


Attached you will find my recommendations for the estimation logic which should be 
incorporated into AODS. The outlined procedure is the product of meetings with 
Oanny Mistretta, Bert Fang, and myself an November 5, 12, 19, 1980; and the review 
I provided on December 3, 1980. The primary objectives were to significantly reduce 
computation time, number of D.C. iterations, provide a reliable edit technique, and 
not increase storage requirements. The key assumptions which underlie the approach 
are: 

1. The measurement parti als do not change enough to affect the process due to 
"moderate" changes in the state. This assumption was tested by Danny Mistretta 

in GTDS. 

2. The solutions are not noise dominated so that significant sampling can be 
done without appreciable resulting errors. This assumption Is made as a 
result of numerous error analyses using 12 to 24 hours of data. 

3. All of the spurious data can be edited on the first D.C. iteration if the 
total state vector error is "moderate," enabling the data population to be 
frozen for subsequent D.C. iterations. This assumption was made based on 
my observations of performance in GRTS and DEBTAP. 

4. Idle time in the system should be used to advantage. 

5. Forward and backward integration and data searching is undesirable. 

Assumptions 1 and 3 are guarded in the design by recomputation and edit if 
the assumptions are violated. The key design features which are related to 
the objectives and assumptions are: 

a. The partial s are frozen after the first D.C. iteration of each slide 
(unless th.e total state correction exceeds predefined limits). This 

eliminates integration of the variational equations every D.C. itera- 
tion. Also, the measurement partials can be stored in single precision. 

b. Data can be sampled down to one observation every minute or 2 to make 
storage available for the measurement partials. The sample rate will 
be an input variable. 

c. Under the assumption of a "moderate" state vector error, tne iterative 
residual edit technique can identify all the spurious data (which would 
eventually be discovered) on the first D.C. iteration. If the correc- 
tion to the state exceeds a predefined limit, the edit procedure is 
repeated on the next D.C. iteration also. 
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d. The covariance matrix itself is not used and so time can be saved by 
simply solving the system of m equations in m unknowns for the state 
only (as opposed to computing the inverse) by Gaussian Elimination 

(suggested by Bert Fang). 

e. If idle time exists after D.C. convergence, the partials and O-C's can 
be precomputed for all observations which may be in the next D.C. slide 
This will enable the converged solution to be ready closer to real time 

f. A simple algorithm derived by Bert Fang eliminates the need to store 
the predicted residuals. 

g. The design provides for epoch to always be at or after the latest data 
point. This eliminates forward and backward integration and data 
searching. 

If further questions arise during the design, implementation, or checkout of these 
algorithms and logic, please feel free to contact me. 


Jerome Teles 
Attachment 

Distribution: Mr. McGarry/582. 1 

Mr. Tasaki/582.1 
Mr. Mistretta/582.2 
Mr. Newman/ 582. 2 
Ms. Pajerski/582.2 
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AO PS ESTIMATION LOGIC 


I. Data Assumptions 


A. Data will be sampled at one reduced observation every 2 minutes (variable). 
Doppler data will be formed by two successive frames at the input data rate. 
Note: The averaging interval must be saved. The time between averaging 
end times will be equal to the sampled data interval requested. 


B. Storage must be allocated for two 10 x 1 measurement partials per frame. 
Note: A possible option is to set up separate storage for Doppler only 
observations versus range and Doppler. In this case, only one 10 x 1 
partial must be saved for the Doppler only case. In addition, space must 
be' allocated for an edit flag, current 0-C. 


C. The data arc will be the smallest arc greater than the specified desired 
arc length. Whole passes will always be used (or whatever partial pass 
remains in storage after data wrap around). 


II. Differential Correction Procedure 


A. The initial slide will be performed as follows: 


1. Define the data arc according to I.C. 


2. Define epoch as the last data point in the arc. Propagate the state 
to epoch. 

3. Propagate the state and variational s from epoch to the earliest data 
point. Compute partials mapped to epoch and Q-C's. 0-C 1 s and partials 
are saved in storage. 


4. Pre-edit O-C's with maximum 0-C, elevation, and/or height of ray path 
edit as appropriate. Note: All previously stored edit flags must be 
cleared prior to the pre-edit. Also, the data arc should be checked 
after the pre-edit. 


5. 


6 . 


Form the normal matrix, right-hand side, and q by 
and f\ fo-cjr f: f Co-c) L , ^ 'To -cV 

* 1 1 -v/, f /'■rkvTr J ^ tr ~ < 


rwrz EpTvf 




1 1 , 


4 


where i f edit points indicate that only those points which do not have 
an edit flag set are summed in. 


The correction to the state is formed by solving the system {F 
by Gaussian elimination. 


Attachment 
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i * -^-rFVifc^)J 

7. The predicted RMS is formed by S>*. " * *■ 

RMS 3 = "$r~ 

8. If the maximum number of edit loops, INLOOP (input variable), is 
reached or i f j •& -f&u* Defaul t serct =\co»), the first itera- 
tion is complete. Start the next iteration at Step II. A. 11. 

9. Predicted residuals Ri are formed for all observations not edited. 

Ki* -k Cfo-ch - 


a. Set edit flags on observations for which /R;/> R'5 e where R Is 
an input variable (Default a 3). Subtract the associated 
and F^I^Co-cXi from F r VP and . and from 

a. - * 


b. If no observations are edited in this edit loop, this D.C. itera- 
tion is complete. Start the next Iteration at Step II. A. 11. 

Otherwise, recompute 4% as in Step II. A.£and perform another 
edit loop as In Steps II. A. 7., II. A. 8., and II. A. 9. 

11. Several decisions must now be made. 

a. Has this iteration of the D.C. converged? If so, the current state 
Is sent to the EXEC for real-time requirements. Convergence will 
be defined by: 

sJ, l&rl < PCo^\y D e f au ]t V\:s,vv)-s ( to ,a>l /&«?< 

a*i isfri < yconv. 

or «2. I < ZcCOW Otfa { \L Sf.CON t,- OOt 

b. Has this iteration of the D.C. diverged? If so, this slide is ter- 
minated. The EXEC is informed to remain in the propagate mode and 

transmit a divergence message. The divergence conditions are 
defined below: 

• /. Edit reduced arc length below acceptable limits, m 
or *2. All new observations edited out, m 

or / a'P/ > PC S PI / Default ( VFLdv) - Oo I c.v, 2. v^/ ; , 

* or / > i/ZLOly 

m 

or *4, I A P L I > R AT w _ £ / A defaul t ZATlox - 2 m 

cr f 0r seC ond and subsequent iterations. 

c. If neither convergence nor divergence has occurred, the next itera- 
tion is started at Step II. A. 12. 
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a. If the maximum number of iterations, MAXDC, (Default MAXDC 2 3 4) 
have been taken, reduced convergence is tested for using tests in 
Step II. A. II. a. but multiplying PCONV, VCQNV, and SECONV by 3. 

If reduced convergence is met, the EXEC is notified of this condi- 
tion and the solution is accepted. If not, the same action is 
taken in divergence in Step II. A. 11. b. 

b. If the current correction is larger than linearity assumptions, 
another complete Iteration is performed by returning to Step II. 

A. 3. ( POSUV VSLUA/ ) 3 (3K/f, ) 

c. Otherwise the new state, is propagated over th^j|ata arc r T 
without the variational equations. O-C's and F'Kdfo-cl 

is reformed. 


A new correction and statistics are computed as in Steps II. A. 
6, 7, and 8. Processing then skips to Step II. A. 11. 


B. Subsequent slides are accomplished as, follows: 

1. Determine the new data arc. 

2. Determine if precomputed partials and O-C's are available. 

a. If so, the predetermined epoch is checked to see if it is later 
than the last data point. If not, the old epoch state is advanced 
to the time of the last data point along with the state transition 
matrix from old epoch to new. 

The prestored partials are mapped to the new epoch by multiplication 
with this transition matrix. If the epoch is all right, the state 
and variationals are propagated over the new data which has been 
received since the last slide processing. O-C's and partials mapped 
to epoch are stored for these observations. Processing continues 
as in Step II. A. 4. 

b. If precomputed partials are not available, processing continues as 
in Step II. A. 2. 


C. D.C. precomputation is performed as follows if invoked by the EXEC. 

1. The epoch is predetermined at current time plus LEADTM (Default 
LEADTM = 30 minutes). 

2. O-C's arid measurement partials are computed for all observations in 

the previous slide by integrating the current state and variationals 
from new epoch to oldest data point. The edit flags are left in their 
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previous state and a quality control state and statistics are determined 
as in Steps II. A. 5., 6., 7., and 8. Control then returns to the EXEC 
with a status flag being set to indicate precomputation is complete. 


APPENDIX F 
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UPDATES MADE TO AODS REQUIREMENTS 
DEFINITION DOCUMENT 


This appendix contains a list of updates made to the AODS 
requirements definition document. 


List of updates made to AODS Requirements Definition Document: 


Pase 

Section 

Type of Change 

2-09 

2-10 

2.2 

Replace last 2 bullets on page 2-09 (through 2-10). 

2-16 

2. 3.1. 5 

Replace R5.1; add R5.6.2. 

2-17 

2.3. 1.5 

Replace R5.7; add R5.7. 1 and R5.7.2. Replace R5.8, 
R5.8.1, R5.8.2; add R5.8.3 and R5.8.4, Replace 
R5.10; add R5.ll, R5.11.1, and R5.11.2. 

2-27 

through 

2-30 

2.3.2 

Replace figures 2-9, 2-10, 2-11, and 2-12. Add 
another figure for Process 5.4. 

2-35 

2.3.2 

Replace P5.1.3, P5.2.3, P5.2.4, and P5.4; add P5.4.1 
P5.4.2, and P5.4.3. Renumber P5.4 to P5.5; renumber 
P5.5 to P5.6; renumber P5.6 to P5.7. 

2-44 

2-45 

2.4.5 

The functional specifications for estimation are 
defined in Reference 10, memorandum entitled "Recom- 
mended Estimation for AODS" by J. Teles, January 8, 
1981, and modification No. 1 dated January 16, 1981. 
Both are attached to these updates. 

B-07 

B.2 

Redefine ESTIMATION CONTROL PARAMETERS; add CONVER- 
GENCE/DIVERGENCE PARAMETERS. 

B- 13 

B.5 

Redefine DC STATISTICS, DC SUMMARY, and EDITING 
STATISTICS. 

B- 14 

B. 5 

Redefine RESIDUAL REPORT. 

C- 11 

C. 1.5 

Redefine Estimatir.i Control Parameters Input Message 

C- 30 

C.2.7 

Redefine DC Summary and Statistics Report. 
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Page Section Type of Change 

C- 32 C.2.8 Redefine DC Residuals Report. 

R"1 Add Reference 10 as follows: Memorandum entitled 


"Recommended Estimation Logic for AODS" by J. Teles 
January 8, 1981. 



Updates to Section 2.2: 


Replace the last 2 bullets on page 2-9 with the following: 

• AODS will be capable of performing batch estimation over a user-specified 
minimum data span which will never be larger than 48 hours. In addition, 
AODS must be capable of handling a maximum of 125 observation pairs in each 
batch of data. 

• AODS will be capable of generating two types of reports during each differ- 
ential correction (DC) slide: 

- The DC Residual Report, if generated, will be generated either (1) after 
and "last" inner edit loops of each iteration or (2) after the "last" 
iteration on each batch of data. 

- The DC Summary and Statistics Report, if generated, will be generated 
either (1) after each DC iteration or (2) after the "last" iteration of 
each DC slide. 



Updates to Section 2. 3. 1.5: 


■; P'-rf 

Replace R5.1: 

R5.1 AODS will perform differential correction on the most recent 

fixed-length minimum data span (specified through control 
parameters) of observation data. The observation data used 
will be whole passes except when data wrap around occurs. 

Replace R5.6.2: 

R5.6.2 Unless directed otherwise, the measurement partials will only 

be computed on the first iteration. The linearity test described 
in R5.8.3 will determine if recomputation is necessary. 

Replace R5.7; add R5.7.1 and R5.7.2: 

R5.7 AODS will perform an edit loop during the first (or, on demand, 

subsequent) iteration of each DC slide based upon the predicted 
residuals and estimation statistics (specified through control 
parameters) . 

R5.7.1 The computed measurements and associated partials will remain 

unchanged during this process. 

R5.7.2 The edit loop will terminate upon either (1) maximum number of 

loops this iteration (maximum = 10) or (2) no observations were 
edited during the predicted residual versus sigma test (input 
parameter) . 

Replace R5.8, R5.8.1, and R5.8.2; add R5.8.3 and R5.8.4: 

R5.8 AODS will test for DC slide convergence, divergence, arid line- 

arity violation at the end of each iteration. 

R5.8.1 AODS will declare a new state solution at the point of conver- 

gence. Convergence is defined in Reference 10, "AODS Estimation 
Logic," memorandum Sections II. A. 11(a) and II. A. 12(a). 
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R5.S.2 

R5.8.3 

R5.8.4 

Replace R5.10: 

R5.10 

Add R5.ll, R5.I1.1, 
R5.ll 

RS. 11.1 
R5.11.2 


2 


AODS will remain in the propagate mode if divergence occurs. 
Divergence is defined in Reference 10, Sections II. A. 11(b) 
and II. A. 12(a). 

AODS will perform another iteration if neither convergence 
nor divergence has occurred. The linearity test defined in 
Reference 10, Section II. A. 12(b) will be performed to deter 
mine if recomputation of partial s and another edit loop will 
be done on the next iteration. 

AODS will declare the current iteration as the "last" itera- 
tion of this DC slide if either convergence or divergence 
occurs. 


AODS will be. capable of generating a DC Residual Report. This 
report, If generated, will be output either (1) after the first 
and "last" edit loops of each iteration or (2) after the "last" 
iteration of each DC slide. 

and R5.11.2: 

AODS will "precompute" values needed for the next DC slide prior 
to the actual receipt of the next data pass. This will be done 
for all slides except the initial slide. 

The new epoch will be predetermined as the current epoch + fixed 
lead time (input parameter). 

Measurement residuals and partials will be computed over all 
observations in the previous slide. 
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Updates to Section 2.3.2: 

Replace P5.1.3: 

P5.1.3 Move epoch to either (1) the end of the estimation time span 

or (2) current epoch + lead time if precompute being performed. 

Replace P5.2.3: 

P5.2.3 Compute observations based on the current state at the obser- 

vation time and, If required by linearity test, compute meas- 
urement partial s wrt epoch state. 

Replace P5.2.4: 

P5.2.4 Compute and accumulate the normal equations and normal matrix 

and perform pre-editing based upon maximum 0-C, elevation 
angle. 

Replace P5.4; add P5.4.1, P5.4.2, and P5.4.3: 

P5.4 Perform an inner edit loop. 

P5.4.1 Compute edit statistics S e> RMS based on nonedited observations. 

P5.4.2 Compute predicted residuals for each measurement. 

P5.4.3 Edit based upon (input) R sigma test over predicted residuals. 

Renumber P5.4 to P5.5 

Renumber P5.5 to P5.6 


Renumber P5.6 to P5.7 



ORIGINAl JO 

OF POOR QUALITY ' | 

J 

** * 

\ 

Date Dictionary Changes to B.2: Process Input Messages 

ESTIMATION CONTROL PARAMETERS = Maximum number of iterations for each DC slide. 

+ Sample frequency for observations (secs). "] 

I 

I 

•f Minimum estimation data span. 

'] 

+ Observation standard deviations. o 

+ Lead time for next DC precomputation. 

+ S Q multiplier for inner loop edit. 

+ Pre-edit criteria. 

+ Maximum number of edit loops (maximum of 10). 

+ Edit test tolerance. 

+ Convergence/divergence parameters. 

+ Residuals Report Control Switch. 

+ DC Summary and Statistics Report Control Switch. 

CONVERGENCE/DIVERGENCE = Position correction convergence tolerance. 

PARAMETERS 

+ Velocity correction convergence tolerance. 

+ S. convergence tolerance. 

0 3 

+ Maximum position correction allowable. 

+ Maximum velocity correction allowable. 

+ Position and velocity correction differences 
multi pi ier. 

+ Position linearity tolerance. 


+ Velocity linearity tolerance. 
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| Data Dictionary Changes to B.5: Estimate State 

j| DC STATISTICS = $ e at each inner loop, 

+ Q summed at each inner loop. 

i 

■\ 

1 

+ Predicted RMS at each inner loop. 

■i 

'j + Convergence/di vergence indicator. 

+ Linearity indicator. 

1 

DC SUMMARY = DC epoch. 

+ DC start time. 

+ DC end time. 

+ Previous state. 

+ Current state, 

+ A priori state. 

+ state correction. 

+ Solve- for map. 

+ Number of solve- for parameters 
+ Iteration number. 

+ Slide number. 

+ Number of inner loops this iteration. 

EDITING STATISTICS = Number of observations in slide. 

+ Number of observations used this iteration. 


+ Number of observations edited this iteration. 
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RESIDUAL REPORT 3 Computed measurement pair. 

+ 0-C pairs. 

+ Predicted residual pairs. 

+ Station/TDRSS ID numbers. 


+ Observation edit tags. 



H 
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C.2.7 DC SUMMARY AND STATISTICS REPORT 


MESSAGE BLOCK ATTRIBUTES: 


Whole report 3 534 bytes 


Record 1 3 

header + 

frame 1 + fill 

3 20 + 184 + fill 3 256 

Record 2 = 

header + frame 2 + fill 

3 20 + 160 + fill 3 256 

Record 3 = 

header + 

frame 3 + fill 

3 20 + 190 + fill 3 256 

1 block 3 

record 1 

+ record 2 + record 3=3 records 

FRAME 1 FORMAT: 




Variable 

M 

Dimension 

Description 

DCEPCH 

R*8 

1 

Epoch 

DCSTRT 

R*8 

1 

Start time of estimation data span 

DCEND 

R*8 

1 

End time of estimation data span 

SE 

R*4 

10 

S g at each innerloop 

QSUM 

R*4 

10 

Q summed at each Innerloop 

XPREV 

R*8 

10 

Previous state vector 

FRAME 2 FORMAT: 




Variable 

Type 

Dimension 

Description 

XCURR 

R*8 

10 

Current state vector 

XAPR ‘ 

R*8 

10 

A priori state vector 

FRAME 3 FORMAT: 



Variable 

Type 

Dimension 

Description 

RMS 

R*8 

10 

Predicted RMS at each innerloop 

XUPD 

R*8 

10 

State correction vector 

I STATE 

1*2 

10 

Parameter numbers 

• 
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FRAME 3 FORMAT: (Continued) 


Variable 

Im. 

Dimension 

Description 

NSTATE 

1*2 

1 

Number of solve- for parameters 

NTOTAL 

1*2 

1 

Total number of observations available 

NUSED 

1*2 

1 

Number of observations used 

NITER 

1*2 

1 

Iteration number 

NBATCH 

1*2 

1 

Slide number 

ICONVG 

1*2 

1 

Convergence/Divergence Indicator: 


= 0, no convergence/divergence this 
iteration 

= 1, convergence ( PCONV * VCONV tests) 

= 2, convergence (SECONV test) 

= 3, reduced convergence (maximum 
iteration but 3* PCONV, VCONV, 
SECONV) 

= 4, diverged (data arc length after 
edit less than minimum estimation 
span) 

= 5, diverged (all new observations 
edited) 

= 6, diverged (POSDIV, VELDIV tests) 

= 7, diverged (RATCOR tests) 

= 8, diverged (maximum iterations) 


NLOOP 

1*2 

1 

Number of inner edit loops this 
iteration 

LINTST 

L*2 

1 

Linearity Indicator: 

= True, do not recompute partials or 
edit loop 

= False, recompute partials and edit 
loop 


C. 2,8 DC RESIDUALS REPORT 
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MESSAGE BLOCK ATTRIBUTES: 


1 frame 
1 record 
256 
256 

1 block 
FRAME FORMAT: 
Variable 
IOBTYP 


1 line of report (48 bytes) 
header + 4 frames + fill 
20 + 192 + fill 
212 + fill 
125 records 


I EDIT ( I ) 


Im. 

Byte 


Dimension 


Byte 


Description 

Observation Type: 

= 1, TDRSS one-way 

= 2, TDRSS two-way 

= 3, TDRSS hybrid 

= 4, S-band one-way 

= 5, S-band two-way 

Edit Flag (I = 1, range; 1=2, 
Dopper) : 

= 0, not edited 

= 1, edited by DC during edit loop 

= 2, edited during preprocessing 

= 3, edited by DC for maximum 0-C 

= 4, edited by DC for minimum eleva- 

tion (USB) or ray path angle 
(TDRSS) 


i 

ITDRSF 

Byte 

1 

TDRSS ID (forward link) 

j 

ITDRSR 

Byte 

1 

TDRSS ID (return link) 

I 

ISTATF 

Byte 

1 

Forward link station ID 
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FRAME FORMAT: 

(Continued) 


Variable 

1m. 

Dimension 

ISTATR 

Byte 

1 

ISPARE 

Byte 

1 

OBTIME 

R*8 

1 

0BS(1) 

R*8 

1 

OBS ( 2 ) 

R*8 

I 

RES I D ( 1 ) 

R*4 

1 

RES ID( 2 ) 

R*4 

1 

PRESID(l) 

R*4 

1 

PRES ID ( 2 ) 

R*4 

1 


Description 

Return link station ID 
Spare location 
Time tag 

Computed range observation 
Computed Doppler observation 
Range residual 
Doppler residual 
Predicted residual for range 
Predicted residual for Doppler 
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C. 1.5 ESTIMATION CONTROL PARAMETERS INPUT MESSAGE 
MESSAGE BLOCK ATTRIBUTES: 


1 frame 

3 Estimation 

control 

parameters set (128 bytes) 

1 record 
256 

1 block 

= 1 frame + 

3 128 + fill 

3 1 record 

fill 


FRAME FORMAT: 

Variable 

Type Dimension 

Description 

DCSPAN 

R*4 

1 

Estimation time span (size of batch 
of data in seconds) 


R*4 

1 

Sample frequency for observations 
(seconds) 

SEMULT 

R*4 

1 

S e multiplier for innerloop editing 

TMLEAD 

R*4 

1 

Lead time for DC precomputation 
(seconds) 

MAXITR 

1*2 

1 

Maximum number of iterations to be 
performed per slide 

INLOOP 

1*2 

1 

Maximum number of inner edit loops 
a 1 1 owed 

OBSSTD(I.J) 

R'*4 

2.5 

Observation Standard Deviations: 


I = Measurement Type 
3 1, range 
= 2, Doppler 


J = Observation Type 
= 1, one-way TDRSS 
= 2, two-way TDRSS 
= 3, three-way TDRSS 
= 4, one-way SRE 
= 5, two-way SRE 


* *1 fl 


Variable Type 

I ROUT 1*2 


IDCOUT 1*2 


RESMAX 

R*4 

ELVMIN 

R*4 

RAVANG 

R*4 

EDTOL 

R*4 

PCONV 

R*4 

VCONV 

R*4 

SECONV 

R*4 

POSDIV 

R*4 

VELDIV 

R*4 

RATCOR 

R*4 

POSLIN 

R*4 

VELLIN 

R*4 






Dimension 


Description 


1 Residual Report Output Control Switch: 

= 0, no report 

3 1, report generated after last itera- 
tion on each batch of data 

3 2, report generated after first and 
last inner edit loops at each 
iteration on a batch of data 

1 DC Summary and Statistics Report Output 

Control Switch: 

3 0, no report 

3 1, report generated after last itera- 
tion on a batch of data 

3 2, report generated after every itera- 
ti on 

5 Maximum 0-C value for each observation 

type 

1 Minimum acceptable elevation angle for 

SRE data (degrees) 

1 Maximum acceptable ray path angle for 

TDRSS data ( 

1 Edit test tolerance 

1 Position correction convergence tolerance 

1 Velocity correction convergence tolerance 

1 S g convergence tolerance 

1 Maximum allowable position correction 

1 Maximum allowable velocity correction 

1 Position and velocity correction 

differences multiplier 

1 Position linearity tolerance 

1 Velocity linearity tolerance 
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